Re: (side-)effects and ...
On 07/05/2015 04:29 PM, Stefan Ram wrote: But why do we not have a common and well-known term for the counterpart, that something does not modify the state of the world, but that the state of the world does influence the value (behaviour) of a call such as »datetime.datetime.now().time()«? And this is the intention of my post: Maybe there is such a term, and I just missed to learn it so far? So, do you know a term for the phenomenon that can be found in Python but not in mathematics and consists in the state of the world influencing the value of an expressions? Variables that are changed from an outside environment are "Volatile". https://en.wikipedia.org/wiki/Volatile_%28computer_programming%29 It isn't used in python, though I think maybe it should be. Cheers, Ron -- https://mail.python.org/mailman/listinfo/python-list
Re: Lawful != Mutable (was Can Python function return multiple data?)
On 06/20/2015 10:50 PM, Rustom Mody wrote: Here is Eric Snow: | Keep in mind that by "immutability" I'm talking about*really* | immutable, perhaps going so far as treating the full memory space | associated with an object as frozen. For instance, we'd have to | ensure that "immutable" Python objects like strings, ints, and tuples | do not change (i.e. via the C API). The contents of involved | tuples/containers would have to be likewise immutable. Even changing | refcounts could be too much, hence the idea of moving refcounts out to | a separate table. | | This level of immutability would be something new to Python. We'll | see if it's necessary. If it isn't too much work it might be a good | idea regardless of the multi-core proposal. Does the second para look like CPython implementation or python-the-language? Also note the 'Even' in the first para. ie Eric is talking of low-level (ie thread-safety, refcounting etc) immutability after the even and higher level semantic immutability before It seems to me, this will take a lot more changes to python overall. Adding a way to raise an exception if an object is mutated would be a good initial step. Have it turned off by default. I think it will be needed to test how any of the above is working. It may also allow some multiprocessing just by avoiding raising any MutatedObject exceptions. Cheers, Ron -- https://mail.python.org/mailman/listinfo/python-list
Re: Set a flag on the function or a global?
On 06/16/2015 05:15 AM, Steven D'Aprano wrote:
On Tuesday 16 June 2015 10:24, Ron Adam wrote:
>Another way is to make it an object with a __call__ method.
>
>The the attribute can be accessed from both outside and inside dependably.
That's what functions are, objects with a __call__ method:
py> (lambda: None).__call__
Yes ;-)
One slight disadvantage is that functions don't take a "self" parameter by
default, which means they have to refer to themselves by name:
def spam():
print spam.attr
Here's a fun hack:
py> from types import MethodType
py> def physician(func):
... # As in, "Physician, Know Thyself":-)
... return MethodType(func, func)
...
py> @physician
... def spam(this, n):
... return this.food * n
...
py> spam.__func__.food = "spam-and-eggs "
py> spam(3)
'spam-and-eggs spam-and-eggs spam-and-eggs'
How about this?: (paste it into your console)
#-
import sys
class EDir:
long = False
def __call__(self, obj=None):
if obj == None:
d = sys._getframe(1).f_locals
else:
d = dir(obj)
return [x for x in d if self.long or not x.startswith("_")]
edir = EDir()
edir()
edir(edir)
edir.long = True
edir(edir)
edir.long = False
edir(edir)
#--
I didn't test how that works from other modules or in nested scopes. Also
replacing None with a unique sentinel object may be better so dir(None)
will work.
Cheers,
Ron
--
https://mail.python.org/mailman/listinfo/python-list
Re: Set a flag on the function or a global?
On 06/15/2015 08:07 PM, Chris Angelico wrote: On Tue, Jun 16, 2015 at 9:57 AM, Steven D'Aprano wrote: >I have two ideas for this, a module-level global, or a flag set on the >function object itself. Remember that the usual way of using this will be >"from module import edir", there are two obvious ways to set the global: > >import module >module.dunders = False > ># -or- > >edir.__globals__['dunders'] = False > > >Alternatively, I can use a flag set on the function object itself: > >edir.dunders = False > For most situations, the last one is extremely surprising - attributes on functions aren't normally meant to be changed by outside callers, Or inside callers either. You can't be sure of the name and there is no self. it always feels wrong (they belong to the function itself). But since this is interactive, I'd advise going for the absolute simplest, which this would be. Go for the function attribute IMO. Another way is to make it an object with a __call__ method. The the attribute can be accessed from both outside and inside dependably. Cheers, Ron -- https://mail.python.org/mailman/listinfo/python-list
Re: Rule of order for dot operators?
On 05/19/2015 02:25 AM, Chris Angelico wrote: On Tue, May 19, 2015 at 12:43 PM, Ron Adam wrote: >Having just implementing something similar for nested scopes, it turns out >it can't be operators because if it was, then the names y and z would be >resolved in the wrong scope. > > y = "m" > z = "n" > a = x . y . z > >Which of course wouldn't do what we want. > > a = x . "m" . "n" > >And most likely this would give an error. If you want to implement the dot as an operator, you could do it by having a special syntactic element called an "atom", which is used for these kinds of identifier-like tokens. The dot operator could then take an object and an atom, and effectively return getattr(obj, stringify(atom)). I'm fairly sure this would result in the same syntax as Python uses. I think it's better not to. What practical things can be done if the dot was an operator and names after dots where parsed as atoms? What I did was parse a name to a subtype of tuple with elements of strings. [return name.with.dots] becomes this in memory after parsing. [keyword_object name_object] Using dots as operators would make that... [keyword_object name_object dot_object atom_object dot_object atom_object] This would require the interpreter to do in steps what a single function call can do all at once. Cheers, Ron -- https://mail.python.org/mailman/listinfo/python-list
Re: Rule of order for dot operators?
On 05/18/2015 09:32 PM, Rustom Mody wrote: >In particular, each .foo() need not return a string - it might return anything, >and the following .bah() will work on that anything. For an arbitrary binary operator ◼ x ◼ y ◼ z can group as (x◼y)◼z or x◼(y◼z) One could (conceivably) apply the same rule to x.y.z Except that x.(y.z) is a bit hard to give a meaning to!! Yes. Having just implementing something similar for nested scopes, it turns out it can't be operators because if it was, then the names y and z would be resolved in the wrong scope. y = "m" z = "n" a = x . y . z Which of course wouldn't do what we want. a = x . "m" . "n" And most likely this would give an error. The name-part after the dot is evaluated in the next inner scope. y is resolved in x's scope, and z is resolved in y's scope. Which is why you can implement objects with closures, but you need to delay name resolution to do that. Which is what the "." does. Pythons attribute lookup is a bit more complex than this of course. https://docs.python.org/3.4/howto/descriptor.html Cheers, Ron -- https://mail.python.org/mailman/listinfo/python-list
An experiment with blocks of object code and other meta ideas.
I've been playing around with a experimental script language that executes
object code lists directly and am looking for others who might like to help.
The first version was written in python. The original idea came from
wondering if it is possible to replace python's byte code with nested
object code lists. As I worked on it, it became clear it would also make a
nice script language on it's own so I decided to test how it would work
independently of python first.
Currently it's implemented in scheme so it can be compiled to C and a stand
alone executable.
The design is simple enough that converting it to use python objects and
using the python C API should be fairly straight forward.
I can update the original written-in-python version if anyone is
interested. It's quite a bit behind the scheme version right now. It might
make an interesting module.
Here's a few command line examples...
==> def [hello] [
... (print "Hello World\n")
... ]
==> (hello)
Hello World
==> set a 23/41
==> set b 3/2
==> (+ a b)
169/82
==> for x [1 2 3 4 5] [
...(print x "\n")
... ]
1
2
3
4
5
==> set conds [
... (< a 6)
... (== b 2)
... not-done
... ]
==> let [a b not-done] [7 2 0]
==> (or conds)
1
==> (and conds)
0
And of course it does execute files too. :-)
{-- guess-my-number.mta
GUESS MY NUMBER GAME
The computer picks a number and you
try to guess it.
---}
def [guess] [
set n (random 10)
set msg "Guess a number from 0 to 10: "
loop [
(print msg)
catch error
[set g (int (read-line))]
if (not (empty? error))
[set msg "What?, guess again: "]
elif (> g n)
[set msg "Too high, guess again: "]
elif (< g n)
[set msg "Too low, guess again: "]
else
[break]
]
(print "Good guess!\n")
]
(guess)
I've been told it looks like a combination of scheme, tcl, and python.
This script-language tests a number of ideas I've been interested in.
Keywords are objects too! They can be bound to names and executed later in
another place or returned by expressions to be executed.
Blocks are nested lists of object code that can be passed around. Actually
programs are nested lists of object codes. It's just the outer most block.
These features make it an interesting meta language to experiment with.
If you think you may be interested in helping with this project, (It's open
source), you can find it here.
https://github.com/Ronald-Adam/magic-meta
https://github.com/Ronald-Adam/magic-meta/wiki/1.-Home
I'm hoping some of you may be interested in helping out as a group project
with the possibility of bringing some of the ideas back to python in some
form. Possibly as a script language that can be used in projects.
There is lots of opportunities to make improvements and additions as there
are zero users currently.
It's still very early in it's development, so don't expect too much at this
time.
Cheers,
Ron
--
https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 04/19/2015 05:42 PM, BartC wrote: So I'm aware of some of the things that are involved. (BTW that project worked reasonably well, but I decided to go in a different direction: turning "J" from a mere syntax into an actual language of its own.) Something you might try with your new language is to have an editor that can parse the source text to a tokenised "text" data file. It should be a fairly direct text to text translation, so putting it into the editor should be doable. Once you get that far, you can add pluggable token parsers to the editor that can unparse the token files to a specific user format for editing, and reparse it back to the standardised token file for storage. Now the users can choose a customised dialect of your language. And the compiler will work on a single token file type. This will also remove the need for pretty printers and formatters as they will be built into the editors pluggable token parser. Just have the editor tokenise and then immediately untokenise and you just checked for syntax errors and reformatted the program. The highlighter could also work with the token parser as well. The only catch is how to handle compile and run time errors. The editor will need to read an error file and translate it back to the source. I think it's doable but it will be tricky to get it to work well. The reason to make the split at tokens is, it's at a stage that most of what is needed is already in a text editor. The token file format becomes the bridge that spans the gap between the user/editor and the compiler/interpreter. Then your compiler/interpreter is all implementation details that work on a single standardised token file format rather than unformatted text files. Ron -- https://mail.python.org/mailman/listinfo/python-list
Re: Great Math Mystery
On 04/17/2015 11:03 AM, Steven D'Aprano wrote: On Fri, 17 Apr 2015 07:47 pm, Fetchinson . wrote: >>>In an altercation with the police, complying with their orders greatly >>>increases your chances of survival. >> >>Ah, the definition of a police state: where ordinary people, whether >>breaking the law or not, are forced by fear of death to obey the police >>at all times, whether the police are acting legally or not. > >I think you are grossly mischaracterizing that sentence of the OP. He >simply makes an observation: in an altercation with the police, >complying with their orders greatly increases your chances of >survival. Is this observation/statement true or false? Based on >empirical data from the past 50 years (in the US and elsewhere) I'd >say it's true by a huge margin. Which is*exactly my point*. "Failure to obey arbitrary commands from random police officers, whether legally justified or not, may carry the penalty of summary execution at the discretion of the officer" is a defining characteristic of police states. This is but one subset of the possibilities that could lead to the same valid advise. Keep in mind that many officers are citizens too, at least where I live, who have jobs that put them in extremely dangerous situations fairly often. Taking too long to rationally think about a situation could mean the police officer is shot instead of the criminal with a gun. There are some combinations of conditions that will result in a certain percentage of outcomes of a certain kind. I think the original statement (Quite possibly from a fortune cookie program.) recognises that concept (as well as yours.) Take a thousand officers, each who respond to a thousand calls a year, and there will be a few (very tragic) mistakes. (and hopefully many more fortunate interventions.) We can maybe shift the proportion of mistakes vs interventions, but I don't see how training officers to shoot after being shot is a good idea. We will likely need to pay a whole lot more to get people to take those jobs. Of course it does not excuse willing abuse of authority. Most cases of police power abuse here are more likely to be related to an individual officers state of mind and/or motives at the time rather than being due to instructions higher up. Possibly there is a way to use Python and statistics to calculate some of these values. With data of course... Number of officers. number of responses. Percent of responses where suspects have deadly weapons. Percent of incorrect judgements within some critical time frame by people in safe conditions. Percentage of incorrect judgements of people in dangerous conditions. Percentage of incorrect judgements of people in safe, but perceived dangerousness conditions.. etc... Would be possible to calculate a norm or average from that kind of info? It is also the type of number people don't want to know about or discuss. -Ron I made no comment on the OP's intention for making that statement. Perhaps he was making an ironic comment on the state of US law enforcement; perhaps he thinks he is being genuinely helpful; perhaps this is his way of mocking those killed. I don't know. Whether he is a fascist who thinks police states are wonderful, or a liberal who thinks they are terrible, he described a police state. Whether he knew it at the time or not. -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python - block grouping (spaces)
On 04/16/2015 01:41 PM, Steven D'Aprano wrote:
>2. Having been an employer, it is difficult to force programmers to use
>any particular editor or style. Different editors handle tabs and spaces
>differently. This is all a bloody nightmare with Python.
Do you really expect us to believe for a microsecond that the choice
between "4 spaces" or "tab" is worse than the C brace wars?
You know I've never thought braces where the problem in a language, and in
python, not having them isn't a problem either.
The reason I dislike C is due to the amount of boiler plate and the low
level of code, which requires managing memory, declaring prototypes and
including headers. All of which I think are much more troublesome and
harder to get right than any amount of braces.
Both sides have advantages, but Python's design is meant to represent code
in an easier to see and read way. Representing blocks by indention is
consistent with that. (And so is outlines in written language.)
I could equally like a language where blocks are literal code objects that
can be assigned to names. In that case the block delimiters would be
consistent with that language design and that would be perfectly fine to
me. The code would be representing what it does in an expected and useful way.
block = {statement_1; statement_2; ...}
The cases in between seem a bit unclean to me however. Where braces are
used to define blocks that aren't exposed. I think it's ok, but it also
seems a bit unclean to me. Adding more noise than necessary to the code.
But I understand at some time, when a language was designed it may have
been that it made parsing the language simpler. (it does.) Or it may have
just been the language designers preference at that time.
But still, I think the whole braces are good/evil is over stated. There
are lots of more important things in languages to consider.
Cheers,
Ron
--
https://mail.python.org/mailman/listinfo/python-list
Re: python admin abuse complaint
Xah Lee wrote: For anyone reading this thread and interested in my opinions, i have written many essays related to this and netiquette. Many of which detail other similar incidences that i personally experienced, such as freenode's irc ban in #emacs channel. If you are interested, they can be found on my website, search for “ban xah lee”. Xah, Often (in the past) most of your posts have come across as complaints or ones pointing out problems or comparisons of the negative sort. Your overall negative tone is just one of the reasons you get labeled a troll. I suggest you try to be less confrontational and more positive. Use your expertise and intelligence to help others but don't be offended if they don't agree with you. There's more than one way to do almost everything and sometimes the best way for "a person" to do it is the way that person is able to grasp it. Regards, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Intra-package References?? (again)
[EMAIL PROTECTED] wrote:
> Hi Python list,
>
> I have been struggleling with this before, but have never been able to
> find a good solution.
> The thing I dont understand is, I follow the guide here:
> http://docs.python.org/tut/node8.html#SECTION00842
> And have the same setup as the packages howto here:http://
> docs.python.org/tut/node8.html#SECTION00840
>
> But when I want to use Intra-package References, I need to put the
> path to the packages explicit like this:
> #sys.path.append('/path/to/pack/')
> Before I can make import like this:
> #from Sound.Effects import echo
> from within the karaoke.py (just to stay with the tut)
> If I print the sys.path from the same file, I can see that
> #/path/to/pack/Sound/Filters/
> is in the path.
>
> Is there something that I completely is missing or could someone
> please show me how, by example, how I use Intra-package References.
>
> Best regards
>
> Marc
If your package is in pythons path, all it should need is an empty
__init__.py file in the package and also in the sub package Filters also.
If your program is a stand alone program that may be installed someplace
not in pythons sys.path, then I've been using a some what different model.
I'm not sure what others think of it yet, but it's working well for me.
[karoki_program_dir] (may not be in pythons sys.path)
karoki.py
[lib]
[tests]
__init__.py
(unit tests here)
[filters]
__init__.py
(various filters here)
(other local modules/packages here)
And in karoki.py add the local lib directory to the front of sys.path
before your local module imports.
lib = os.path.abspath(os.path.join(__file__, '..', 'lib'))
sys.path.insert(0, lib)
This also makes sure it's the program location path, and not the current
console directory.
For running tests, I use a command line option.
python karoki.py --test
Cheers,
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Re: time.time or time.clock
Fredrik Lundh wrote: > John Machin wrote: > >> AFAICT that was enough indication for most people to use time.clock on >> all platforms ... > > which was unfortunate, given that time.clock() isn't even a proper clock > on most Unix systems; it's a low-resolution sample counter that can > happily assign all time to a process that uses, say, 2% CPU and zero > time to one that uses 98% CPU. > > > before the introduction of the timeit module; have you considered it? > > whether or not "timeit" suites his requirements, he can at least replace > his code with > > clock = timeit.default_timer > > which returns a good wall-time clock (which happens to be time.time() on > Unix and time.clock() on Windows). Thanks for the suggestion Fredrik, I looked at timeit and it does the following. import sys import time if sys.platform == "win32": # On Windows, the best timer is time.clock() default_timer = time.clock else: # On most other platforms the best timer is time.time() default_timer = time.time I was hoping I could determine which to use by the values returned. But maybe that isn't as easy as it seems it would be. Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: time.time or time.clock
John Machin wrote: > On Jan 14, 7:05 am, Ron Adam <[EMAIL PROTECTED]> wrote: >> I'm having some cross platform issues with timing loops. It seems >> time.time is better for some computers/platforms and time.clock others, but > > Care to explain why it seems so? > >> it's not always clear which, so I came up with the following to try to >> determine which. >> >> import time >> >> # Determine if time.time is better than time.clock >> # The one with better resolution should be lower. >> if time.clock() - time.clock() < time.time() - time.time(): >> clock = time.clock >> else: >> clock = time.time >> >> Will this work most of the time, or is there something better? >> > > Manual: > """ > clock( ) > > On Unix, return the current processor time as a floating point number > expressed in seconds. The precision, and in fact the very definition > of the meaning of ``processor time'', depends on that of the C > function of the same name, but in any case, this is the function to > use for benchmarking Python or timing algorithms. > > On Windows, this function returns wall-clock seconds elapsed since the > first call to this function, as a floating point number, based on the > Win32 function QueryPerformanceCounter(). The resolution is typically > better than one microsecond. > [snip] > > time( ) > > Return the time as a floating point number expressed in seconds since > the epoch, in UTC. Note that even though the time is always returned > as a floating point number, not all systems provide time with a better > precision than 1 second. While this function normally returns non- > decreasing values, it can return a lower value than a previous call if > the system clock has been set back between the two calls. > """ > > AFAICT that was enough indication for most people to use time.clock on > all platforms ... before the introduction of the timeit module; have > you considered it? I use it to time a Visual Python loop which controls frame rate updates and set volocities according to time between frames, rather than frame count. The time between frames depends both on the desired frame rate, and the background load on the computer, so it isn't constant. time.clock() isn't high enough resolution for Ubuntu, and time.time() isn't high enough resolution on windows. I do use timeit for bench marking, but haven't tried using in a situation like this. > It looks like your method is right sometimes by accident. func() - > func() will give a negative answer with a high resolution timer and a > meaningless answer with a low resolution timer, where "high" and "low" > are relative to the time taken for the function call, so you will pick > the high resolution one most of the time because the meaningless > answer is ZERO (no tick, no change). Some small fraction of the time > the low resolution timer will have a tick between the two calls and > you will get the wrong answer (-big < -small). If the difference is between two high resolution timers then it will be good enough. I think the time between two consectutive func() calls is probably low enough to rule out low resolution timers. In the case of two > "low" resolution timers, both will give a meaningless answer and you > will choose arbitrarily. In the case of two low resolution timers, it will use time.time. In this case I probably need to raise an exception. My program won't work correctly with a low resolution timer. Thanks for the feed back, I will try to find something more dependable. Ron -- http://mail.python.org/mailman/listinfo/python-list
time.time or time.clock
I'm having some cross platform issues with timing loops. It seems time.time is better for some computers/platforms and time.clock others, but it's not always clear which, so I came up with the following to try to determine which. import time # Determine if time.time is better than time.clock # The one with better resolution should be lower. if time.clock() - time.clock() < time.time() - time.time(): clock = time.clock else: clock = time.time Will this work most of the time, or is there something better? Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Would Anonymous Functions Help in Learning Programming/Python?
Scott David Daniels wrote: > Ron Adam wrote: >> Scott David Daniels wrote: >>> Ron Adam wrote: >>>> How about this? >>>> def integrate(fn, x1, x2, n=100):... >>> The point was a pedagogic suggestion, ... >> I understood your point. I just found it interesting since I've been >> trying to extend my math (for use with python) skills in this area. > > Ah, sorry. I had realized I wasn't explicit in my first message. Yes, I wasn't trying to correct you. I'm sorry if it came across that way. > Yes, a perfectly fine integration. There's still something about it that bothers me. I think it may be the n=100 rather than delta='.0001', or some other way to specify the minimal error. (Yes, it's a bit off topic.) > You can then (and this is a major jump to get used to): > import functools > > Sine = functools.partial(integrate, math.cos, 0.0, n=100) I haven't played around with .partial yet. I wonder if it could be used in dispatching situations where the function signatures differ? > Similarly, you can define a derivative that will behave fairly well, > all without examining the definition of the function being operated > upon. I'll get around to doing that at some point. ;-) I also have a class that solves equations that takes a function in a similar way. It uses the same method used by HP calculators to solve TVM equations. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Factory function with keyword arguments
Steven D'Aprano wrote: > On Sun, 23 Sep 2007 03:55:45 -0500, Ron Adam wrote: > >> Steven D'Aprano wrote: >>> I'm writing a factory function that needs to use keywords in the >>> produced function, not the factory. Here's a toy example: > > [snip] > > Thanks everyone who answered, you've given me a lot of good ideas. > > I've run some tests with timeit, and most of the variants given were very > close in speed. The one exception was (not surprisingly) my version that > builds a tuple, puts it in a list, then converts it to a dict, *before* > doing anything useful with it. It was 3-4 times slower than the others. > > George's version, with two definitions of foo(), was the fastest. The > second fastest was the variant using exec, which surprised me a lot. I > expected exec to be the slowest of the lot. Unfortunately, I doubt that > these would scale well as the factory becomes more complicated. The one with exec (the others less so) will depend on the ratio of how often the factory is called vs how often the foo is called. If the factory is called only once, then exec only runs once. If the factory is called every time foo is needed, then it will be much slower. So your test needs to take into account how the factory function will be used in your program also. Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Factory function with keyword arguments
Steven D'Aprano wrote:
> I'm writing a factory function that needs to use keywords in the produced
> function, not the factory. Here's a toy example:
> I thought of doing this:
>
> def factory(flag):
> if flag: kw = 'spam'
> else: kw = 'ham'
> def foo(obj, arg):
> kwargs = dict([(kw, arg)])
> return obj.method(**kwargs)
> return foo
>
> Is this the best way of doing this? Are there any alternative methods
> that aren't risky, slow or obfuscated?
Looks ok to me. It can be simplified a bit.
def factory(flag):
kw = 'spam' if flag else 'ham'
def foo(obj, arg):
return obj.method(**{kw:arg})
return foo
Cheers,
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Re: Would Anonymous Functions Help in Learning Programming/Python?
Scott David Daniels wrote: > Ron Adam wrote: >> >> Scott David Daniels wrote: >>> Cristian wrote: >>>> On Sep 21, 3:44 pm, Ron Adam <[EMAIL PROTECTED]> wrote: >>>> >>>>> I think key may be to discuss names and name binding with your friend. >>> Here's an idea: >>> >>> import math >>> >>> def sin_integral(start, finish, dx): ... >>> def cos_integral(start, finish, dx): ... >>> generalize and separate the integration technique from the >>> function it integrates. >> How about this? >> It's based on the apple basic program example in How to Enjoy Calculus. >>Ron >> >> import math >> def integrate(fn, x1, x2, n=100):... >> def fn(x): ... >> print "Area of fn:", integrate(fn, 0, 2) >> print "Area of cos fn:", integrate(math.cos, 1, 2) > > The point was a pedagogic suggestion, i.e. I understood your point. I just found it interesting since I've been trying to extend my math (for use with python) skills in this area. >"Try taking your > friend along this path." I wasn't trying to do a particularly > good job integrating, simply trying to show how you could > motivate first-class functions by showing a "useful" and > "fun" (at least to an engineer) function that cries out > for higher order functions. In my experience engineers > often want a "reason its useful" before engaging with an > idea. I'll bet that after a few such experiences he'll see > how passing around functions and (later) making functions from > from functions is a great tool to have in his toolbox. Once > he sees that, there will be no problem. Yes, I agree. Another useful thing I've found is to store functions in a dictionary and call them (dispatching) based on some data value. Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Would Anonymous Functions Help in Learning Programming/Python?
Scott David Daniels wrote: > Cristian wrote: >> On Sep 21, 3:44 pm, Ron Adam <[EMAIL PROTECTED]> wrote: >> >>> I think key may be to discuss names and name binding with your friend. > > Here's an idea: > > import math > > def sin_integral(start, finish, dx): > total = 0.0 > y0 = math.sin(start) > for n in range(1, 1 + int((finish - start) / float(dx))): > y1 = math.sin(start + n * dx) > total += (y0 + y1) > y0 = y1 > return total / 2. * dx > > > def cos_integral(start, finish, dx): > total = 0.0 > y0 = math.sin(start) > for n in range(1, 1 + int((finish - start) / float(dx))): > y1 = math.cos(start + n * dx) > total += (y0 + y1) > y0 = y1 > return total / 2. * dx > > generalize and separate the integration technique from the > function it integrates. How about this? It's based on the apple basic program example in How to Enjoy Calculus. Ron import math def integrate(fn, x1, x2, n=100): # Calculate area of fn using Simpson's rule. width = float(x2 - x1) / n area = fn(x1) if n % 2 != 0: # make sure its even n += 1 for n in range(1, n): x = x1 + n * width if n % 2 == 0: area += 2.0 * fn(x) else: area += 4.0 * fn(x) area += fn(x2) return area * (width / 3.0) def fn(x): return x**2 print "Area of fn:", integrate(fn, 0, 2) print "Area of cos fn:", integrate(math.cos, 1, 2) print "Area of sin fn:", integrate(math.sin, 1, 2) Area of fn: 2.667 Area of cos fn: 0.0678264420216 Area of sin fn: 0.956449142468 -- http://mail.python.org/mailman/listinfo/python-list
Re: Would Anonymous Functions Help in Learning Programming/Python?
Cristian wrote: > On Sep 21, 3:44 pm, Ron Adam <[EMAIL PROTECTED]> wrote: > >> I think key may be to discuss names and name binding with your friend. How >> a name is not the object it self, like a variable is in other languages. >> For example show him how an object can have more than one name. And discus >> how names can be bound to nearly anything, including classes and functions. > > I could discuss name binding but it would be great if Python said this > itself. After all, you can even bind a module with the foo = bar > syntax by using __import__ function. If function definitions followed > the same pattern, I think a beginner would subconsciously (maybe even > consciously) realize that function names are just like everything > else. Actually, this would be helpful for many people. If you come > from a language like Java you're used to thinking of attributes and > methods as living in different namespaces. I think a new syntax will > encourage seasoned programmers think in a more Pythonic way. I could see methods having their own keywords. Then functions defined in classes would be static methods without any extra work. But to do that would break a lot of already existing code as well as confuse a lot of current users. > Python has done a very good job in easing people into programming. My > friend doesn't come to me very often because the syntax is clear and > simple and the builtin datatypes allow you to do so much. My goal is > that I would never have to explain to him about name binding; that > he'd pick it up by learning the language on his own. He's learned > lists, dictionaries and even some OOP without me. I don't think name > binding would be a stretch. Chances are he'll run into a gotcha where an object has two names and sort it out that way. Which is why I suggested starting there. It will save him some grief if he hasn't run into it yet. >> You could also discus factory functions with him. Once he gets that a >> function can return another function, then it won't be so much of a leap >> for a function to take a function as an argument. > > I think this isn't the most intuitive way of approaching first order > functions. The Python tutorial does this by defining a function, then assigning it to another name and calling it from the new name. http://www.python.org/doc/current/tut/tut.html > It's true that if a function can return another function > then a function must be first order (i.e., it's just like any other > variable), but that seems almost backwards to me. I think it would > make more sense to have beginners _know_ that functions are like all > other variables and can therefore be passed by other functions or > returned by other functions. That I think would be better accomplished > if they define functions the same way you would define other variables > that you know can be passed and returned. I think it gets awkward fairly quick if you try and work out how to do this. There have been requests in the past to have functions assigned to names like other things. The nice thing about the current syntax is it more closely resembles what you would type at call time, so it is more self documenting. def sum(x, y): return x + Y total = sum(1, 2) I think changing that would be trading one type of clarity for another. Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Would Anonymous Functions Help in Learning Programming/Python?
Cristian wrote: > My hope is to subtly reinforce the notion that functions are data > and can be passed around. The current function declaration doesn't > help with this. Creating a function and assigning it to a name is > exactly what Python does, why not have it come out in the syntax? It's > not necessary, yes, but I think it would be helpful for teaching > purposes. I think key may be to discuss names and name binding with your friend. How a name is not the object it self, like a variable is in other languages. For example show him how an object can have more than one name. And discus how names can be bound to nearly anything, including classes and functions. > Again, it's not necessary as much as it's more intuitive and obvious > what's going on. This helps a beginner sort out the process from the > syntax without taking it on faith. They can see the class declaration > and see "I'm defining just another attribute to this class only this > time it happens to be method". > > There is nothing functionally lacking in Python. I'm just curious if > there's anything Python can do syntax-wise to help a person better > grasp programming ideas and Python's inner workings. You could also discus factory functions with him. Once he gets that a function can return another function, then it won't be so much of a leap for a function to take a function as an argument. Of course he'll figure out all this sooner or later anyway. You can't be an engineer without a fair amount of brain cells committed to processing abstract concepts. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Bruno Desthuilliers wrote: > Ron Adam a écrit : >> >> TheFlyingDutchman wrote: >> >>> I am not talking about the way it does it, but rather, the way it >>> could do it or... could have done it. That requires no knowledge of >>> how the interpreter currently does it unless I am proposing something >>> that no interpreter in the world could ever do. > (snip) >> So if you can find a way to do things like removing self in python in >> such a way that it doesn't require adding more to the Core interpreter, >> then it might be considered. > > By who ? As far as I'm concerned, I don't want 'self' to be removed, and > I'm probably not the only one here. The term "might be considered" in this case is a very very small possibility. It would need to be a very good solution which has some very nice benifits over the current way. As you say below, it's probably not possible. This was more of a challenge to get anyone who thinks it's worth doing to learn more about how python works rather than just propose arbitrary ideas. >> What I've found is as my skills improve, I take more advantage of being >> able to modify and/or introspect how things work. This allows more >> choices on how I might solve a particular problem. > > The changes required by removing self would make most of this either > painfull or near impossible AFAICT. Right, It would have a cascade effect in many places. >> I also think there a lots of improvements that could be made to other >> parts of python such as the libraries that would be of much more >> practical benefit. > > indeed. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman wrote: > I am not talking about the way it does it, but rather, the way it > could do it or... could have done it. That requires no knowledge of > how the interpreter currently does it unless I am proposing something > that no interpreter in the world could ever do. Yes, there are a couple of things that could have been changed. But from what I can tell there are a number of reasons why things where chosen to be the way they are. Two of those reasons is to make the core C code smaller and easier to maintain and also to make it easier to understand how things work. Exposing the inner workings as visible python code vs hidden C code helps both of those. Another benefit of exposing more of the class machinery of Pythons objects as python code, is it makes it possible to modify more of how things work directly with python code. A good way to see how this works is studying how descriptors and properties work. http://users.rcn.com/python/download/Descriptor.htm You will find there is much more of python written in python than it may first seem. In some cases the built in classes and modules are written in C, yet they still work as if they are written in Python. So if you can find a way to do things like removing self in python in such a way that it doesn't require adding more to the Core interpreter, then it might be considered. What I've found is as my skills improve, I take more advantage of being able to modify and/or introspect how things work. This allows more choices on how I might solve a particular problem. I also think there a lots of improvements that could be made to other parts of python such as the libraries that would be of much more practical benefit. Regards, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Break up list into groups
Matimus wrote: > Excellent work! One more modification and I get below 10us/pass: > > def getgroups(seq): > groups = [] > push = groups.append > iseq = iter(xrange(len(seq))) > for start in iseq: > if seq[start] & 0x80: > for stop in iseq: > if seq[stop] & 0x80: > push(seq[start:stop]) > start = stop > push(seq[start:]) > return groups > > -Matt Looks good to me. :-) So a generator versions would be... (not tested) def getgroups(seq): iseq = iter(xrange(len(seq))) for start in iseq: if seq[start] & 0x80: for stop in iseq: if seq[stop] & 0x80: yield seq[start:stop] start = stop yield seq[start:] (I also wanted to compare this to Georges solution, maybe later.) Now if there is some way to generalize this so it can be used in a broader range of situations without loosing too much of it's efficiency. Of course then maybe group by would be better. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Break up list into groups
Matt McCredie wrote: > That certainly is fast, unfortunately it doesn't pass all of the tests. > I came up with those tests so I don't know how important they are to the > original poster. I modified it and came up with a generator and a > non-generator version based (roughly) on your algorithm, that are almost > as quick, and pass all of the tests. Some of the modifications were done > just to make it quicker, so it would be fair when comparing against the > other methods. I hard-coded the comparison instead of using a function > and created a function that directly generates and returns a list > instead of a generator. I would probably use the generator version in my > code, but wrapping `list' around a generator adds about 4us (on my > machine). Anyway, getgroups7 passes all of the tests I mentioned and it > was timed at 10.37usec/pass. The down side: the code doesn't seem nearly > as elegant. > > Matt In most cases you wouldn't wrap the generator version in a list(), but use it directly as a loop iterator. A little renaming of variables helps it be a bit more elegant I think ... def getgroups8(seq): groups = [] iseq = iter(xrange(len(seq))) for start in iseq: if seq[start] & 0x80: for stop in iseq: if seq[stop] & 0x80: groups.append(seq[start:stop]) start = stop groups.append(seq[start:]) return groups This passes all the tests and runs about the same speed. Cheers, Ron > > def gengroups7(seq): > iseq = iter(xrange(len(seq))) > start = 0 > for i in iseq: > if seq[i]&0x80: > start = i > break > else: > return > for i in iseq: > if seq[i]&0x80: > yield seq[start:i] > start = i > yield seq[start:] > > > def getgroups7(seq): > groups = [] > iseq = iter(xrange(len(seq))) > start = 0 > for i in iseq: > if seq[i]&0x80: > start = i > break > else: > return groups > for i in iseq: > if seq[i]&0x80: > groups.append(seq[start:i]) > start = i > groups.append(seq[start:]) > return groups > > > > > > -- http://mail.python.org/mailman/listinfo/python-list
Re: Break up list into groups
Matimus wrote: > I did some more experimenting and came up with the code below. It > shows several methods. When run, the script tests the robustness of > each method (roughly), and profiles it using timeit. The results from > running on my laptop are shown below the code. Try this one... def groupdata(data, fn): start = 0 for n in range(1, len(data)): if fn(data[n]): yield data[start:n] start = n yield data[start:] print list(groupdata(l, lambda x: x & 0x80)) Cheers ;-) Ron > > seqs = [# Original: > [0xF0, 1, 2, 3, 0xF0, 4, 5, 6, 0xF1, 7, 8, 0xF2, 9, 10, 11, > 12, 13, > 0xF0, 14, 0xF1, 15], > # Single entry: > [0xF0, 1, 2, 3], > # empty > [], > # No values with 0x80 set > [1, 2, 3, 14, 15], > # Does not start with a value that has 0x80 set > [1, 2, 3, 14, 15, 0xF0, 1, 2, 3]] > > expected = [# Original: > [[0xF0, 1, 2, 3], [0xF0, 4, 5, 6], [0xF1, 7, 8], [0xF2, 9, > 10, 11, 12, 13], > [0xF0, 14], [0xF1, 15]], > # Single entry: > [[0xF0, 1, 2, 3]], > # empty > [], > # No values with 0x80 set > [], > # Does not start with a value that has 0x80 set > [[0xF0, 1, 2, 3]]] > > def gengroups0(seq): > group = None > for val in seq: > if val & 0x80: > if group: yield group > group = [] > try: > group.append(val) > except AttributeError: > pass > if group: yield group > > def getgroups0(seq): > groups = [] > group = None > for val in seq: > if val & 0x80: > if group: > groups.append(group) > group = [] > try: > group.append(val) > except AttributeError: > pass > if group: > groups.append(group) > return groups > > def gengroups1(seq): > idxs = [i for i,v in enumerate(seq) if v&0x80] > for i,j in zip(idxs,idxs[1:]+[None]): > yield seq[i:j] > > def getgroups1(seq): > idxs = [i for i,v in enumerate(seq) if v&0x80] > return [seq[i:j] for i,j in zip(idxs,idxs[1:]+[None])] > > # Similar to the partition method on strings > def partition(seq,f=None): > if f is None: > f = lambda x:x > for i,v in enumerate(seq): > if f(v): > return seq[:i],[seq[i]],seq[i+1:] > return seq,[],[] > > def rpartition(seq, f=None): > if f is None: > f = lambda x:x > for i,v in zip(range(len(seq)-1,-1,-1),seq[::-1]): > if f(v): > return seq[:i],[seq[i]],seq[i+1:] > return ([],[],seq) > > def gengroups2(seq): > while seq: > seq, key, val = rpartition(seq, lambda x: x&0x80) > if key and val: yield key+val > > def getgroups2(seq): > groups = [] > while seq: > seq, key, val = rpartition(seq, lambda x: x&0x80) > if key and val: > groups.append(key+val) > return groups > > def getgroups3(seq): >groups = [] >for i in seq: > if 0x80 & i: >groups.append([i]) > else: >groups[-1].append(i) >return [x for x in groups if x] > > seq = seqs[0] > if __name__ == "__main__": > from timeit import Timer > import __main__ > for i in range(4): > fname = "getgroups"+str(i) > f = getattr(__main__,fname) > print fname > for i,(s,e) in enumerate(zip(seqs,expected)): > print "test %d:"%i, > try: > if f(s) == e: > print "pass" > else: > print "fail" > except: > print "error" > > t = Timer(fname+'(seq)', >'from __main__ import seq,'+fname) > print "%.2f usec/pass" % (100 * t.timeit(number=10)/ > 10) > print > > > Output from running the above: > getgroups0 > test 0: pass > test 1: pass > test 2: pass > test 3: pass > test 4: pass > 14.85 usec/pass > > getgroups1 > test 0: pass > test 1: pass > test 2: pass > test 3: pass > test 4: pass > 13.81 usec/pass > > getgroups2 > test 0: fail > test 1: pass > test 2: pass > test 3: pass > test 4: pass > 56.38 usec/pass > > getgroups3 > test 0: pass > test 1: pass > test 2: pass > test 3: error > test 4: error > 16.23 usec/pass > > `getgropus2' fails test 0 because it produces a reversed list. That > can easily be fixed by re-reversing the output before returning. But, > since it is by far the slowest method, I didn't bother. > > `getgroups3' is a method I got from another post in this thread, just > for comparison. > >>From my benchmarks it looks like getgroups1 is the winner. I didn't > scour the thread to test all the methods however. > -- http://mail.python.org/mailman/listinfo/python-list
Re: webbrowser module bug?
Paul Boddie wrote: > Ron Adam wrote: >> Reseting the default browser with the gnome default application window >> confirmed this. The browser selection can either have the quotes around >> the args "%s" paremteter, or not depending on how and what sets it. >> >> Seems to me it should be quoted unless spaces in path names are never a >> problem in Linux. So this could be both a python bug and a Gnome desktop >> bug. Firefox probably does the right thing by putting the quotes around >> it, but that causes problems for webbrowser.py, which doesn't expect them. > > Quoting arguments in the way described is the safe, easy option (with > some potential problems with ' characters that can be worked around), > and I imagine that it's done precisely because other applications > could pass a path with spaces as the URL, and that such applications > would be invoking the command in a shell environment. Sadly, this > conflicts with any other precautionary measures, causing a degree of > "overquoting". > > Resetting the GNOME default is a workaround, but I'm not convinced > that it would be satisfactory. What happens if you try and open an > HTML file, in the file browser or some other application which uses > the desktop preferences, where the filename contains spaces? I'm not sure how to test this. Most things I can think of call the web browser directly. Maybe a link in an email? Yes, it is a work around. The webbrowser module needs to be smarter about quotes. As I said, this is fixed in 2.6 already. I emailed the module maintainer, and will probably file a bug report too. Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: webbrowser module bug?
Ron Adam wrote:
> Got it.
>
> It looks like the problem started when I told firefox to make itself
> the default browser. That changed the way webbrowser.py figured out the
> browser to use. So instead of trying them in order, it asked the gnome
> configure tool for it.
>
> def register_X_browsers():
> # The default Gnome browser
> if _iscommand("gconftool-2"):
> # get the web browser string from gconftool
> gc = 'gconftool-2 -g /desktop/gnome/url-handlers/http/command
> 2>/dev/null'
> out = os.popen(gc)
> commd = out.read().strip()
> retncode = out.close()
>
>
> After this commd is:
>
> '/usr/lib/firefox/firefox "%s"'
>
> It's then split, but the quotes aren't removed. I'm not sure why this
> doesn't show up in 2.6. Maybe it's been fixed there already.
A bit more follow up... so others can find this and avoid a lot of
debugging, head scratching, computer smashing or worse.
Reseting the default browser with the gnome default application window
confirmed this. The browser selection can either have the quotes around
the args "%s" paremteter, or not depending on how and what sets it.
Seems to me it should be quoted unless spaces in path names are never a
problem in Linux. So this could be both a python bug and a Gnome desktop
bug. Firefox probably does the right thing by putting the quotes around
it, but that causes problems for webbrowser.py, which doesn't expect them.
Since the python trunk (2.6) has been changed to get the browser name in a
different way, it won't be a problem for python 2.6.
To check the args parameter or reset the default browser in the gnome
desktop, use the gnome default application panel.
$ gnome-default-applications-properties
You can then either remove the extra quotes from the "%s" or reset the browser.
Cheers,
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Re: webbrowser module bug?
Ron Adam wrote:
> Paul Boddie wrote:
>> On 25 May, 00:03, Ron Adam <[EMAIL PROTECTED]> wrote:
>>> Is anyone else having problems with the webbrowser module?
>>>
>>> Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25)
>>> [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import webbrowser
>>> >>> webbrowser.open('http://www.python.org')
>>> True
>>> >>>
>>>
>>> It opens firefox as expected, but the url is ...
>>>
>>> file:///home/ron/%22http://www.python.org%22
>> Since %22 is the URL-encoded double-quote character ("), I can only
>> imagine that something is quoting the URL for the shell, resulting in
>> the following command:
>>
>> firefox '"http://www.python.org/";'
>>
>> Or something similar, at least. Firefox 1.5 seems to refuse to open
>> such URLs, though.
>>
>> Paul
>
> Yes, thats it. I've traced it down the the subproccess.Popen call.
>
>
> This works
>
> >>> subprocess.Popen(['firefox', 'http://python.org'])
>
>
>
> This reproduces the problem I'm having.
>
> >>> subprocess.Popen(['firefox', '"http://python.org";'])
>
>
> The quoting does happen in the webbrowser module.
>
> The cmdline is passed as...
>
> ['/usr/lib/firefox/firefox', '"http://python.org";']
>
>
>
> I've traced it back to the following line where self.args is ['"%s"']
>
> Line 187 in webbrowser.py:
>
> cmdline = [self.name] + [arg.replace("%s", url)
> for arg in self.args]
>
> Now I just need to figure out why self.args is double quoted.
Got it.
It looks like the problem started when I told firefox to make itself
the default browser. That changed the way webbrowser.py figured out the
browser to use. So instead of trying them in order, it asked the gnome
configure tool for it.
def register_X_browsers():
# The default Gnome browser
if _iscommand("gconftool-2"):
# get the web browser string from gconftool
gc = 'gconftool-2 -g /desktop/gnome/url-handlers/http/command
2>/dev/null'
out = os.popen(gc)
commd = out.read().strip()
retncode = out.close()
After this commd is:
'/usr/lib/firefox/firefox "%s"'
It's then split, but the quotes aren't removed. I'm not sure why this
doesn't show up in 2.6. Maybe it's been fixed there already.
Cheers,
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Re: webbrowser module bug?
Paul Boddie wrote:
> On 25 May, 00:03, Ron Adam <[EMAIL PROTECTED]> wrote:
>> Is anyone else having problems with the webbrowser module?
>>
>> Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25)
>> [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import webbrowser
>> >>> webbrowser.open('http://www.python.org')
>> True
>> >>>
>>
>> It opens firefox as expected, but the url is ...
>>
>> file:///home/ron/%22http://www.python.org%22
>
> Since %22 is the URL-encoded double-quote character ("), I can only
> imagine that something is quoting the URL for the shell, resulting in
> the following command:
>
> firefox '"http://www.python.org/";'
>
> Or something similar, at least. Firefox 1.5 seems to refuse to open
> such URLs, though.
>
> Paul
Yes, thats it. I've traced it down the the subproccess.Popen call.
This works
>>> subprocess.Popen(['firefox', 'http://python.org'])
This reproduces the problem I'm having.
>>> subprocess.Popen(['firefox', '"http://python.org";'])
The quoting does happen in the webbrowser module.
The cmdline is passed as...
['/usr/lib/firefox/firefox', '"http://python.org";']
I've traced it back to the following line where self.args is ['"%s"']
Line 187 in webbrowser.py:
cmdline = [self.name] + [arg.replace("%s", url)
for arg in self.args]
Now I just need to figure out why self.args is double quoted.
Cheers,
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Re: webbrowser module bug?
Steve Holden wrote:
> Ron Adam wrote:
>> [EMAIL PROTECTED] wrote:
>>> On May 24, 5:03 pm, Ron Adam <[EMAIL PROTECTED]> wrote:
>>>> Is anyone else having problems with the webbrowser module?
>>>>
>>>> Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25)
>>>> [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>> >>> import webbrowser
>>>> >>> webbrowser.open('http://www.python.org')
>>>> True
>>>> >>>
>>>>
>>>> It opens firefox as expected, but the url is ...
>>>>
>>>> file:///home/ron/%22http://www.python.org%22
>>>>
>>>> Which of course doesn't do what is expected.
>>>>
>>>> Any ideas?
>>>>
>>>> Ron
>>> I don't know. This works for me with Python 2.4 on Windows XP SP2. The
>>> docs don't say much (http://docs.python.org/lib/module-
>>> webbrowser.html). Maybe it would be beneficial to read the module's
>>> code? Or use the "register" command manually?
>> It works for me on python 2.4 also, but not on later versions.
>>
>> Looks like I'll need to try to test the url at the point where it calls the
>> browser from webbrowser.py.
>>
>> Can someone else test this on python 2.5?
>>
> On my Windows laptop it works on 2.4.1 and 2.5.1 native, but not on
> 2.5.1 for Cygwin.
Does it mangle the url in the same way?
If so, then that would be enough to file a bug report.
It's maybe not due to the webbrowser module it self, but maybe something
else that's platform dependent?
Can anyone else reproduce this?
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Re: webbrowser module bug?
Brian van den Broek wrote:
> Ron Adam said unto the world upon 05/25/2007 12:28 PM:
>> [EMAIL PROTECTED] wrote:
>>> On May 24, 5:03 pm, Ron Adam <[EMAIL PROTECTED]> wrote:
>>>> Is anyone else having problems with the webbrowser module?
>>>>
>>>> Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25)
>>>> [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>> >>> import webbrowser
>>>> >>> webbrowser.open('http://www.python.org')
>>>> True
>>>> >>>
>>>>
>>>> It opens firefox as expected, but the url is ...
>>>>
>>>> file:///home/ron/%22http://www.python.org%22
>>>>
>>>> Which of course doesn't do what is expected.
>>>>
>>>> Any ideas?
>
>
>
>> It works for me on python 2.4 also, but not on later versions.
>>
>> Looks like I'll need to try to test the url at the point where it calls the
>> browser from webbrowser.py.
>>
>> Can someone else test this on python 2.5?
>>
>> Ron
>
> Works fine for me on ubuntu 7.04 (fiesty) with Python 2.5.1c1, which
> appear to be your set-up, too.
>
> Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25)
> [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import webbrowser
> >>> webbrowser.open('http://www.python.org')
> True
> >>>
>
> Best,
>
> Brian vdB
Thanks,
This is strange. Now I have no idea where to look. (?)
I get the same incorrect results doing...
[EMAIL PROTECTED]:~$ python2.5 -m webbrowser 'http://www.python.org'
Firefox attempts to open...
file:///home/ron/%22http://www.python.org%22
The following works ok:
[EMAIL PROTECTED]:~$ firefox 'http://www.python.org'
Works in the Ubuntu 2.4.4 dist (But blocks until the browser is closed.)
Doesn't work in the Ubuntu 2.5.1c1 dist
Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25)
Doesn't work in the 2.5 maintenance branch
Python 2.5 (release25-maint:54563, May 24 2007, 18:33:45)
Works in the 2.6 branch (trunk)
Works in the 3.0 branch
I'll try uninstalling and reinstalling. The Ubuntu 2.5 dist.
None of the svn versions are on the path, so it shouldn't be a path
conflict with them.
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Re: webbrowser module bug?
[EMAIL PROTECTED] wrote:
> On May 24, 5:03 pm, Ron Adam <[EMAIL PROTECTED]> wrote:
>> Is anyone else having problems with the webbrowser module?
>>
>> Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25)
>> [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import webbrowser
>> >>> webbrowser.open('http://www.python.org')
>> True
>> >>>
>>
>> It opens firefox as expected, but the url is ...
>>
>> file:///home/ron/%22http://www.python.org%22
>>
>> Which of course doesn't do what is expected.
>>
>> Any ideas?
>>
>> Ron
>
> I don't know. This works for me with Python 2.4 on Windows XP SP2. The
> docs don't say much (http://docs.python.org/lib/module-
> webbrowser.html). Maybe it would be beneficial to read the module's
> code? Or use the "register" command manually?
It works for me on python 2.4 also, but not on later versions.
Looks like I'll need to try to test the url at the point where it calls the
browser from webbrowser.py.
Can someone else test this on python 2.5?
Ron
--
http://mail.python.org/mailman/listinfo/python-list
webbrowser module bug?
Is anyone else having problems with the webbrowser module?
Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import webbrowser
>>> webbrowser.open('http://www.python.org')
True
>>>
It opens firefox as expected, but the url is ...
file:///home/ron/%22http://www.python.org%22
Which of course doesn't do what is expected.
Any ideas?
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Re: PYDOC replacement. (Was:Sorting attributes by catagory)
Nick Vatamaniuc wrote: > Thanks for the info, Ron. I had no idea pydoc was that powerful! > -Nick Change *was* to *will be*. It really needed to be re factored. ;-) Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: PYDOC replacement. (Was:Sorting attributes by catagory)
Nick Vatamaniuc wrote: > Ron, > > Consider using epydoc if you can. Epydoc will sort the methods and it > will also let you use custom CSS style sheets for the final HTML > output. Check out the documentation of my PyDBTable module. > http://www.psipy.com/PyDBTable > > -Nick Vatamaniuc Hi Nick, I already have sorting and style sheets taken care of. I'm just trying to get the content of each sub section correct at this point. The overall frame work is finished. I don't think Epydoc can replace the console help() output. The site.py module imports help(), from pydoc.py. That serves as the consoles interactive help mode. When you type help() at the console, you are using pydoc. Some of the differences... Epydoc -- Output formats: - html files - graphs (requires Graphviz) I like this! - pdf files (requires latex) * Requires explicitly generating files first. * Supports file parsing only instead of introspection. Epydoc is more of a complete application and has many nice features such as the graphs and completeness checks, that will make it better than pydoc for creating more complete pre-generated html documents with less work. Pydoc = Output formats: - live interactive console text - live interactive html with a local html server. * no files are generated. (just in the browser cache) * supports custom CSS stylesheets (API data output...) - text - html page - html section (for use in templates) - xml - reST (not yet, but will be easy to do) The reason for having additional output formats is it makes it much easier to use it as a tool to extract documentation from source code to be combined with existing more complete documentation. I am planning on writing output formatters to return docutils and docbook data structures as well. With those, you will be able to convert to latex, pdf, and other formats. The data formats for those are very close to what I'm using, so this should be easy to do. Other side benefits of doing this is that some of the modules in pydoc have been generalized so that they can be used without pydoc. The html server, and the document data and formatter classes, can be used independently of pydoc. The overall total size has not increased much, and it is more modular, maintainable, and extendable. Maintainability is a major concern for any library module or package. Of course it will need to be approved first. ;-) Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Sorting attributes by catagory
This is for a new version of pydoc if I can get the class attributes sorted out. The module level attributes aren't too difficult to categorize. (I might be just too tired to see the obvious.) The original pydoc did this a somewhat round about way, so I would like to find a more direct method if possible. Where dir(obj) is used to get all attributes of a module or class. And they are then sorted into categories depending on what they are. (In order of precedence.) For modules: - imported_items (defined in another module, or is another module) - classes - functions - other_objects (everything else) For classes: - from_else_where(object created someplace else) - inherited_attributes (from parents classes or type) - static_methods_here - class_methods_here - other_methods - properties - getset_descriptors - other_descriptors - other_attributes (everything else) A single function that accepts an object and can return one of the above (or equivalent) strings would be ideal. Finer grained categorizing is ok as long as they don't overlap more than one group. It seems I can get some of these fairly easy with the inspect module, but others I need to test in multiple ways. Any ideas? Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: pydoc and imported modules
[EMAIL PROTECTED] wrote: > When I "from foo import *" in my __init__.py, sometimes module foo's > docs will be expanded in the pydocs. It seems to depend in what > language foo was implemented. > > For example, if you "from math import *" in your __init__.py, you will > see math's members will appear in the resulting pydocs, as though it's > part of your module. The behavior is consistent across the C modules I > am writing. > > However, if you "from foo import *" in your __init__.py, and foo is a > python file (not a module written in C), foo's members don't appear in > the resulting pydocs. This also seems to occur in some boost::python > bindings. > > What is expected behavior? How do ensure foo's docs do or don't appear > in help, regardless of their implementation language? > > Thanks, > Schpok Pydoc doesn't check the __module__ attribute of the items imported, it just displays what is in the modules name space as if it was defined in that module. In __init__.py files where an __all__ variable is defined, it won't show items that aren't in __all__. This is probably what you are seeing. I'm currently rewriting pydoc, so what behavior would you like to see? Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Pydoc Rewrite Discussion at doc-sig list.
Colin J. Williams wrote: > Ron Adam wrote: >> If anyone is interested in participating in discussing the details of the >> PyDoc rewrite/refactoring I've been working on, a discussion is being >> started on the doc-sig list. >> >> [EMAIL PROTECTED] >> >> The goal of this discussion will be to get it to a final finished form so a >> patch can be submitted and a final discussion can take place on the >> python-dev list at a later date. >> >> Thanks and Regards, >>Ron Adam >> > Are there features which exist or planned for Pydoc and which are not > available with epydoc? They are really two different things. Epydoc is an application for producing documentation, Pydoc is more of a live introspection tool. Pydoc *is* primarily the console help function. Many users don't realize that when they use the help() function they are using Pydoc. Since Epidoc is a stand alone application, it has much more freedom to add and extend what it does. Probably Epidoc will always be ahead of Pydoc when it comes to generating separate stand alone documentation. Pydoc produces interactive documentation as needed, it doesn't normally produce any files as you use it. For example while you are working on a project you can be viewing the Pydoc output in a web browser, make changes, and then refresh the browser page to see those changes. Same goes for the builtin help() function and interactive help in console mode. Pydoc can produce both text and html files, but that isn't it's main use. There are several reasons for rewriting Pydoc. One is that as both a tool and a library module, it has developed incrementally over time and is currently limited more so than it should be for both as a tool and as a library module to be used by other programs. It has also gotten to the point where it's not as easy to maintain as it could be. What I'm doing is addressing these issues by making it a package and breaking it down into more modular parts. I'm not trying to make a lot of changes to the output as I see that as a separate issue. But by rewriting the code that produces that output to be more modular, flexible, and easier to maintain, it will make producing better output much easier to do. As a better library tool box, it may be that other tools can use the Pydoc package as a base to build on. So it is a goal to make the basic parts of Pydoc extendable and flexible, but at the same time keeping the interface to each part clear and simple. Some of these parts may be relocated other packages depending on what they do. Are there any specific features you are interested in? Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Pydoc Rewrite Discussion at doc-sig list.
If anyone is interested in participating in discussing the details of the PyDoc rewrite/refactoring I've been working on, a discussion is being started on the doc-sig list. [EMAIL PROTECTED] The goal of this discussion will be to get it to a final finished form so a patch can be submitted and a final discussion can take place on the python-dev list at a later date. Thanks and Regards, Ron Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: from __future__ import absolute_import ?
Peter Otten wrote: > Ron Adam wrote: > >> Peter Otten wrote: >>> Ron Adam wrote: >>> >>>> work >>>> | >>>> |- foo.py# print "foo not in bar" >>>> | >>>> `- bar >>>> | >>>> |- __init__.py >>>> | >>>> |- foo.py# print "foo in bar" >>>> | >>>> |- absolute.py # from __futer__ import absolute_import >>>> |# import foo >>>> | >>>> `- relative.py # import foo >>>> (4) >>>> C:\work\bar>python -c "import bar.absolute" >>>> foo in bar >>>> (5) >>>> >>> import bar.absolute >>>> foo in bar > (4) and (5) are misconfigurations, IMHO. But it's a very common configuration. So it will most likely cause problems for someone. From what I understand these will probably do what I want in python 2.6, which is either import the foo not in bar, or give an error if foo not in bar doesn't exist instead of importing foo in bar. >>> in an absolute-import-as-default environment; >>> >>> import foo >>> >>> would always be an absolute import. >> But what is the precise meaning of "absolute import" in this un-dotted >> case? >> >> Currently it is: >> >> "A module or package that is located in sys.path or the current >> directory". >> >> But maybe a narrower interpretation may be better?: >> >> "A module or package found in sys.path, or the current directory >> and is *not* in a package." > > You'd have to add a not-in-package test to every import - I don't think it's > worth the effort. No, you only need to test the (first) module you explicitly run is in a package. For any imports after that, the absolute import code can exclude any of the package directories for un-dotted top level absolute imports. It may be a performance net gain because there is less disk searching. >> All in all, what I'm suggesting is that the concept of a package (type) be >> much >> stronger than that of a search path or current directory. And that this >> would add a fair amount of reliability to the language. > > I think if you go that way, ultimately you will need some kind of package > registry. I expect that the new import behaviour will get you 99 percent > there with one percent of the hassle. But we will see... It won't need a registry. Check the python-ideas list for further discussion on this. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: PYTHONPATH or any other way to set seachpath (winXP) ?
Stef Mientki wrote:
>> Do you mean something like that?
>>
> import some_module
>> Traceback (most recent call last):
>> File "", line 1, in ?
>> ImportError: No module named some_module
> import sys
> sys.path.append("..")
> import some_module
> Rob,
> thank you very much,
> that's exactly what I want.
> (Why is the obvious so often invisible to me ;-)
>
> cheers,
> Stef Mientki
Just a note, If you run the module from different location, it may not always
work.
The '..' is relative to the location you are running the module from, the
current directory, and not relative to the location of the module is at.
It won't be a problem for you if you can be sure the module is always ran from
the location it is at.
Cheers,
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Re: from __future__ import absolute_import ?
Peter Otten wrote: > Ron Adam wrote: > >> >> work >> | >> |- foo.py# print "foo not in bar" >> | >> `- bar >> | >> |- __init__.py >> | >> |- foo.py# print "foo in bar" >> | >> |- absolute.py # from __futer__ import absolute_import >> |# import foo >> | >> `- relative.py # import foo >> >> >> * Where "work" is in the path. >> >> >> (1) >> >> C:\work>python -c "import bar.absolute" >> foo not in bar >> >> C:\work>python -c "import bar.relative" >> foo in bar >> >> >> (2) >> >> C:\work>python -m "bar.absolute" >> foo not in bar >> >> C:\work>python -m "bar.relative" >> foo not in bar >> >> >> (3) >> >> C:\work>python >> Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] >> on win 32 >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import bar.absolute >> foo not in bar >> >>> import bar.relative >> foo in bar >> >> >> (4) >> >> C:\work>cd bar > > A path below the package level is generally a good means to shoot yourself > in the foot and should be avoided with or without absolute import. Seems so. :-/ >> C:\work\bar>python -c "import bar.absolute" >> foo in bar >> >> C:\work\bar>python -c "import bar.relative" >> foo in bar >> >> >> (5) >> >> C:\work\bar>python >> Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] >> on win 32 >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import bar.absolute >> foo in bar >> >>> import bar.relative >> foo in bar >> >>> >> >> >> >> Case (2) seems like it is a bug. > > I think so, too. This one is the reasons I had trouble figuring it out. I was using the -m command option when I tried to test it. There is a bug report on absolute/relative imports already. I'm not sure if this particular item is covered under it or not. Doesn't sound like it as the bug report address the relative aspects of it. >> Why not also have (4), and (5) do the same as cases (1) and (3)? > > The work/bar directory is the current working directory and occurs in the > path before the work directory. Yes. Unfortunately this is a side effect of using the os's directory structure to represent a python "package" structure. If a package was represented as a combined single file. Then the working directory would always be the package directory. > When bar.absolute imports foo python is > unaware that work/bar/foo.py is part of the bar package. Umm isn't the "bar" stuck on the front of "bar.absolute" a pretty obvious hint. ;-) If you run the module directly as a file... python bar/foo.py or python foo.py Then I can see that it doesn't know. But even then, it's possible to find out. ie... just check for an __init__.py file. Python has a certain minimalist quality where it tries to do a lot with a minimum amount of resources, which I generally love. But in this situation that might not be the best thing. It would not be difficult for python to detect if a module is in a package, and determine the package location. With the move to explicit absolute/relative imports, it would make since if python also were a little smarter in this area. >> in cases (4) and (5), that is the result I would expect if I did: >> >> import absolute # with no 'bar.' prefix. >> import relative >> >> >> From what I understand, in 2.6 relative imports will be depreciated, and >> in 2.7 >> they will raise an error. (providing plans don't change) >> >> Would that mean the absolute imports in (4) and (5) would either find the >> 'foo not in bar' or raise an error? > > No, in 1, 3 -- and 2 if the current behaviour is indeed a bug. This is only > for the relative import which would have to be spelt > > from . import foo Was that a 'yes' for exampels 4 and 5, since 1,2 and 3 are 'no'? > in an absolute-import-as-default environment; > > import foo > > would always be an absolute import. But what is the precise meaning of "
Re: from __future__ import absolute_import ?
Peter Otten wrote: > Ron Adam wrote: > >> from __future__ import absolute_import >> >> Is there a way to check if this is working? I get the same results with >> or without it. >> >> Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) >> [MSC v.1310 32 bit (Intel)] on win 32 > > If there are two modules 'foo', one at the toplevel and the other inside a > package 'bar', > > from __future__ import absolute_import > import foo > > will import the toplevel module whereas > > import foo > > will import bar.foo. A messy demonstration: > > $ ls bar > absolute.py foo.py __init__.py relative.py > $ cat bar/absolute.py > from __future__ import absolute_import > import foo > $ cat bar/relative.py > import foo > $ cat foo.py > print "toplevel" > $ cat bar/foo.py > print "in bar" > $ python2.5 -c 'import bar.absolute' > toplevel > $ python2.5 -c 'import bar.relative' > in bar > > > Another example is here: > > http://mail.python.org/pipermail/python-list/2007-January/422889.html > > Peter Thanks, that helped, I see why I was having trouble. work | |- foo.py# print "foo not in bar" | `- bar | |- __init__.py | |- foo.py# print "foo in bar" | |- absolute.py # from __futer__ import absolute_import |# import foo | `- relative.py # import foo * Where "work" is in the path. (1) C:\work>python -c "import bar.absolute" foo not in bar C:\work>python -c "import bar.relative" foo in bar (2) C:\work>python -m "bar.absolute" foo not in bar C:\work>python -m "bar.relative" foo not in bar (3) C:\work>python Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> import bar.absolute foo not in bar >>> import bar.relative foo in bar (4) C:\work>cd bar C:\work\bar>python -c "import bar.absolute" foo in bar C:\work\bar>python -c "import bar.relative" foo in bar (5) C:\work\bar>python Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> import bar.absolute foo in bar >>> import bar.relative foo in bar >>> Case (2) seems like it is a bug. Why not also have (4), and (5) do the same as cases (1) and (3)? in cases (4) and (5), that is the result I would expect if I did: import absolute # with no 'bar.' prefix. import relative From what I understand, in 2.6 relative imports will be depreciated, and in 2.7 they will raise an error. (providing plans don't change) Would that mean the absolute imports in (4) and (5) would either find the 'foo not in bar' or raise an error? If so, is there any way to force (warning/error) behavior now? Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
from __future__ import absolute_import ?
from __future__ import absolute_import Is there a way to check if this is working? I get the same results with or without it. Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win 32 _Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Module name to filename and back?
Ron Adam wrote: > Is there a function to find a filename from a dotted module (or package) name > without importing it? > > The imp function find_module() doesn't work with dotted file names. And it > looks like it may import the file as it raises an ImportError error exception > if > it can't find the module. (Shouldn't it raise an IOError instead?) > > What I'm looking for is to be able to get the full module name when I have a > filename. And get the full filename when I have the module name. And do > both > of these without importing the module. > > modulename <==> filename > filename <==> modulename I found a partial answer in trace.py. It has a fullmodname() function, but it doesn't do any validation so the name it returns is a guess. Starting with it I tried to make it a bit more complete, but it still needs work. Seems like there should be an easier way. Ron def importname(path): """ Get module or package name from a path name. Return None if path is invalid, or name is not a valid (reachable) package or module. """ path = os.path.normcase(path) if not os.path.exists(path): return if path.endswith(os.sep): path = path[:-1] longest = "" for dir in sys.path: dir = os.path.normcase(dir) + os.sep if path.startswith(dir): if len(dir) > len(longest): longest = dir if longest: base = path[len(longest):] else: # should check if in current dir? return # path not in search sys.path # This need a bit more work, it should also check # for valid parent packages too. if os.path.isdir(path): valid = False for ext in ['.py', '.pyc', '.pyo']: if os.path.isfile(os.path.join(path, '__init__' + ext)): valid = True break else: return base, ext = os.path.splitext(base) name = base.replace(os.sep, ".") if os.altsep: name = name.replace(os.altsep, ".") return name path = "c:\\python25\\lib\\xml\\sax\\handler.py" print importname(path) prints --> xml.sax.handler -- http://mail.python.org/mailman/listinfo/python-list
Module name to filename and back?
Is there a function to find a filename from a dotted module (or package) name without importing it? The imp function find_module() doesn't work with dotted file names. And it looks like it may import the file as it raises an ImportError error exception if it can't find the module. (Shouldn't it raise an IOError instead?) What I'm looking for is to be able to get the full module name when I have a filename. And get the full filename when I have the module name. And do both of these without importing the module. modulename <==> filename filename <==> modulename Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: assert versus print [was Re: The curious behavior of integer objects]
Neil Cerutti wrote: > On 2007-01-16, Ron Adam <[EMAIL PROTECTED]> wrote: >> I have to admit that part of why assert seems wrong to me is >> the meaning of the word implies something you shouldn't be able >> to ignore. While warnings seem like something that can be >> disregarded. > > Experienced C coders expect assert to behave like that. > > The only reason (I know of) to turn off error checking is to > optimize. However, removing tests won't usually make a big enough > speed difference to be worth the burthen of testing two different > versions of the same source code. Ah... but that's the irony. The whole purpose of the existence of the second version you refer to, is to better check the first version. These checks should not change the flow of code that is executed! The problem with assert as a debugging tool, is it *can* change the execution flow by raising a catchable exception. So you do have *two* versions that may not behave the same. Like I suggested earlier, assert should not be turned off *ever*, but should be considered a nicer way to generate exceptions to do value checks. And warnings should never change code execution order, but we should be able to completely turn them off on the byte code level like asserts are when the -O command line option is given. I believe both of these features would be used a lot more if they where like this. > So to me the assert statement is either dubious syntax-sugar or > dangerous, depending on Python's command line arguments. Yep.. unless you use them in a very limited way. > The warning module would seem to have limited applications. > Searching my Python distribution shows that it's used for > deprecation alerts, and elsewhere for turning those selfsame > alerts off. How copacetic! It is the null module. ;-) I think you understand the point I'm trying to make. :-) Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: assert versus print [was Re: The curious behavior of integer objects]
Carl Banks wrote: > Ron Adam wrote: >> There have been times where I would like assert to be a little more assertive >> than it is. :-) >> >> ie.. not being able to turn them off with the -0/-00 switches, and having >> them >> generate a more verbose traceback. > > Personally, I'd rather see it get less assertive, i.e., having it only > work in a special debugging mode. That way people who haven't RTFM > don't use it to make sure their input is correct. > > > Carl Banks Well, the manual could be improved in this area quite a bit. There also really need to be easier to find examples for both assert and warnings use. But it does only work in a special debugging mode. Didn't you RTFM? ;-) http://docs.python.org/ref/assert.html It just happens this mode is turned on by default. So you would like this to be turned off by default. I agree. I think there may be a way to change pythons default startup behavior for this. Warnings generated by warn() on the other hand can be silenced, but not completely ignored. But I also think they could be a more useful and flexible tool for debugging purposes. http://docs.python.org/lib/warning-functions.html I have to admit that part of why assert seems wrong to me is the meaning of the word implies something you shouldn't be able to ignore. While warnings seem like something that can be disregarded. I think maybe the best way to use both may be to combine them... assert warn(...) But I'm not sure that doesn't have problems of it's own. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: assert versus print [was Re: The curious behavior of integer objects]
Steven D'Aprano wrote: > On Mon, 15 Jan 2007 21:01:35 -0600, Ron Adam wrote: > > >> There have been times where I would like assert to be a little more >> assertive >> than it is. :-) >> >> ie.. not being able to turn them off with the -0/-00 switches, and having >> them >> generate a more verbose traceback. > > If you want something more verbose, you have it: > >>>> assert False, "verbose traceback" > Traceback (most recent call last): > File "", line 1, in ? > AssertionError: verbose traceback > > If you want something that won't be turned off by -O, you maybe need to > write your own: > > def assert_(condition, msg=""): > if not condition: > raise AssertionError(msg) > >> Maybe have an alternative 'warn' as an alternative debugging version that >> could >> be set to ignore, soft (print to log), and hard (raise an error). > > Check out the warnings module. Yes, I know it's there. It just seems like assert and warn() overlap currently. Assert doesn't quite fill warn()'s shoes, and warn() isn't as unassertive as assert when it's turned off. A warn statement could be completely ignored and not even cost a function call when it's turned off like assert does now. I don't think it does that currently. Isn't there always some overhead when using the warn() function. Or is there some magic there? An if-raise is just as fast as assert when evaluating as True, so there's no speed advantage there unless you have a large percentage of raises. But it does looks a lot nicer when you want a short positive test, verses a longer negative test with a raise stuck on it. But I think the developers would not consider this to be a big enough matter to be worth changing. So I'll continue to ignore warn(), and also continue to be un-assertive in my python code. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: assert versus print [was Re: The curious behavior of integer objects]
Calvin Spealman wrote: > On 1/15/07, Steven D'Aprano <[EMAIL PROTECTED]> wrote: >> On Mon, 15 Jan 2007 17:50:56 -0500, Calvin Spealman wrote: >> >>> assert foo(0x10) == 0 # Assertions are much better tests than prints :-) >> I dispute that assertion (pun intended). > > Hah! > >> Firstly, print statements work even if you pass the -O (optimize) flag >> to Python. Your asserts don't. > > This is true, but the concept can be adapted to a things like an > assert_() function. > >> Secondly, a bare assertion like that gives you very little information: it >> just tells you that it failed: >> > x = 1 > assert x == 0 >> Traceback (most recent call last): >> File "", line 1, in ? >> AssertionError >> >> To provide the same information that print provides, you need something >> like this: >> >> assert x == 0, "x == %s not 0" % x > > What information would I need to know if my test passed? Nothing, I > say. I only want to know when the tests fail, especially as I add more > of them. Having no output is a great way to know nothing puked. > >> Thirdly, and most importantly, assert and print aren't alternatives, >> but complementary tools. Assertions are good for automated testing and >> simple data validation, where you already know what values you should >> have. Printing is good for interactively exploring your data when you're >> uncertain about the values you might get: sometimes it is hard to know >> what you should be asserting until you've seen what results your function >> returns. > > True, but I intended my statement as a nudge towards more proper > testing. Even when testing things out, I often use an assert rather > than a print, to verify some condition. There have been times where I would like assert to be a little more assertive than it is. :-) ie.. not being able to turn them off with the -0/-00 switches, and having them generate a more verbose traceback. Maybe have an alternative 'warn' as an alternative debugging version that could be set to ignore, soft (print to log), and hard (raise an error). An assert statement is a little clearer than an if...raise... in cases where you want to raise a value exception of some type. But I'm probably in the minority on this one. Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Decimal() instead of float?
Michael B. Trausch wrote: > On Fri, 2006-11-17 at 21:25 +0100, Fredrik Lundh wrote: >> > Some of the lat/long pairs that I have used seem to come out fine, but >> > some do not. Because the mathmatics used with them involve complex >> > equations when determining distance and the like, any error gets >> > massively compounded before a final result is evident. >> >> sorry, but I don't think you have the slightest idea what you're doing, >> really. >> > > Sure, I do. Let's say that I want to work with the latitude > 33.6907570. In Python, that number can not be stored exactly without > the aid of decimal.Decimal(). > > >>> 33.6907570 > 33.6907568 > >>> > As you can see, it loses accuracy after the 6th decimal place. That's > not good enough: I have 8 numbers that need to be exact, and I am only > getting six. That error will propagate throughout any multiplication or > division problem. The error /compounds/ itself: Actually it doesn't loose accuracy until the final decimal place, which is probably much smaller than the accuracy you need unless you are doing theoretical research on very small time frames with ideal numbers. Then, yes you may need to use either numeric or decimal which can support a much higher precision. Numeric is much faster so I would try that first. On the other hand, if you are writing an application that does practical calculations on real measured data, then you have two sources of errors to be concerned with. One is the unseen error from the actual measurements which is probably much bigger than the error you are trying to avoid. And the other is the minuscule error caused by the binary C representation. For example if a device measures a value of 33.6907570, it is a measurement that can be off by +- 0.005 (or more, depending on the accuracy of the device), compared with the error of 0.0001, it is huge. So if you are not already taking into account the larger error, by rounding your results to a proper number of significant digits, then you may have a much bigger problem, and a much larger real error than you realize. So, you first need to manage the errors introduced when the data is created. By doing that, you will probably find it will also resolve the smaller error you are concerned about here. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Steve Holden wrote: > I'm always surprised by the amount of energy that's put into this type > of discussion - even the OP has suggested that this isn't a big issue. > If it's not a big issue why is this thread still going? Every language > has a syntax. Why not just accept it as a given and get on with more > productive activities? It's because it's not an issue with an obviously (clear to everyone) good or bad answer. Obvious bad answer -> short discussion Obvious good answer -> short discussion which spawns many long discussion about the not so obviously details. * Nearly a toss up -> really long discussion that rehashes things over and over from various micro points of view. Even though it's pretty much known this won't change, people still want the clarity of an obvious answer even if an obvious solution doe not exist, so the thread continues. And of course what is obvious or not isn't obvious to everyone, so that too is a long discussion. ;-) But I think this thread has a second underlying attribute that appeals to the participants. It isn't so much an effort to change anything as it is an effort to explore and understand why things where made the way they are. To those who already know, this seems silly, but to those who are still learning, it seems important. This could be broken down a bit more, but then we would get into long debates on the best non-obvious ways to do that. ;-) Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Michael Hobbs wrote: > Ron Adam wrote: >> Michael Hobbs wrote: >> >>> Ron Adam wrote: >>> >>>> LOL, of course it would. I would expect that too after a suitable amount >>>> of >>>> 'brain washing', oops, I mean training and conditioning. ;-) >>>> >>>> >>> Trust me, my brain is quite filthy and doesn't wash easily. I do >>> appreciate aesthetics, which is why still stay with Python, even after >>> programming in Ruby for several months. I've used Java/C/C++ for years, >>> yet I make no complaint about the lack of static typing in Python. Even >>> so, I'd like to think that I know a good thing when I see it. >>> >> I find if I approach things on a learning basis and always presume there are >> things I still don't know. I then tend to get much more help and support >> than >> if I approach things on a 'I'm right/your wrong' basis. Also, if I do turn >> out >> to have a point a view that is not exactly right, it is then much easier for >> me >> to take a new position or even the reverse position and move on. >> >> > To clarify my position, I'm not intentionally being contradictory. In > fact, when I first posed my question, I asked if anyone had a good > reason for why the redundancy should continue to exist. Expecting to get > a nice grammatical counter-example, the only viable answer that anyone > could come up with is the FAQ answer that it improves readability. Since > then, I've been fighting my point that the colon really doesn't improve > readability all that much. And you may be entirely correct that it doesn't improve readability "that much" or not enough to matter. So at some point some body made a choice and now that's what we have. But the situation of readability now is influenced by that choice made then. If it was a close call when abc was designed, enough so that a study was needed to decide, It has now become what we are used to. And familiarity probably has a bigger effect on readability. > In the end, I have to admit that I really couldn't give a flying frog if > the colon is there or not. It's just a colon, after all. I *was* hoping > that I could convince someone to honestly think about it and consider if > the colon is really that noticeable. But so far, the only response that > I've received is that there's that ABC study somewhere and that settles > that. > > - Mike As I said above, it may in fact be the way it is, simply because someone at some point made a choice for what ever reason they had at the time. But changing this particular item at this time isn't something that would be practical. (my opinion) So probably the best you can expect is for a few people to agree with you. Which is fine. If enough people were to agree with you, you could start a group effort to write your own version of python and distribute that. There's nothing preventing anyone from doing that. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Michael Hobbs wrote: > Ron Adam wrote: >> [EMAIL PROTECTED] wrote: >> >>> >>>>> I'm not sure why '\'s are required to do multi-line before the >>> colon. >>> >>>> Special cases aren't special enough to break the rules. >>> >>>> >>> >>>> Georg >>> >>> A bit of a circular answer. >>> >>> >>> >>> Why the rule? -> So not to break the rule? >>> >> >>> >> You proposed to allow leaving off line continuation '\' only in the >>> >> "if", "for" and "while" headers. This is a special case in my eyes. >>> >>> Ron> I wasn't that specific and it was related to Michael's suggestion >>> Ron> the colon wasn't needed. If the need for '\' was dropped in >>> Ron> multi-line block headers, then the colon would be required for an >>> Ron> obvious reason. >>> >>> But \ is used to continue all sorts of statements/expressions, e.g.: >>> >>> x = a + \ >>> b >>> >>> not just conditionals. >>> >>> Skip >>> >> Of course, and your point is? >> >> How about if it be ok to continue to use '\' in headers, but it also be ok >> to >> not to? That would be the backward compatible way to change it. >> >> This doesn't answer the question I was asking, are there any situation where >> it >> would cause problems? And if so, that reason would be a good and explicit >> reason for not making such a change > > To be clear, this is the actual thrust of my argument. It seems > redundant to have *both* line continuations and colons in compound > statements. I've been arguing for the removal of colons, though to be > honest, I'd be content with the opposite approach as well. > > - Mike Well, maybe you should consider working on that instead. I think you will get much less resistance. Consider the following points: * There are not (that I know of) any true multiple line block headers in python but only long block headers with continued lines. * It's probably more beneficial to simplify the more complex cases of multiple continued lines, than it is to simplify the already simple cases of non continued block headers. * The block header can be identified in all cases by the initiating keyword and the terminating colon. (colons in lambda and dicts need to be identified first) * The block header can not always be clearly identified strictly based on indenting as indenting in a block header spanning several lines is completely optional and may vary quite a bit depending on the programmers preferences. * Line continuations are *already* currently optional in other situations. >>> a = (1, ... 1, ... 3, ... 4, ... 5) >>> a (1, 1, 3, 4, 5) >>> b = (6, \ ... 7, \ ... 8, \ ... 9) >>> b (6, 7, 8, 9) * Making line continuations optional requires no changes to the existing library. * Removing colons would require changing block headers for all existing programs and pythons library unless you made the ending colon optional. But that probably would create more confusion and hurt readability more than it improves it. So giving these points, and any others you can think of, which do you suppose has a better chance of being implemented? It also needs to be pointed out that the line continuations are a strong visual indication that a line is continued and not just a aid to the compiler. So there will be resistance to changing that also. (Over and above the general resistance to change most people have.) Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Michael Hobbs wrote: > Ron Adam wrote: >> LOL, of course it would. I would expect that too after a suitable amount >> of >> 'brain washing', oops, I mean training and conditioning. ;-) >> > Trust me, my brain is quite filthy and doesn't wash easily. I do > appreciate aesthetics, which is why still stay with Python, even after > programming in Ruby for several months. I've used Java/C/C++ for years, > yet I make no complaint about the lack of static typing in Python. Even > so, I'd like to think that I know a good thing when I see it. I find if I approach things on a learning basis and always presume there are things I still don't know. I then tend to get much more help and support than if I approach things on a 'I'm right/your wrong' basis. Also, if I do turn out to have a point a view that is not exactly right, it is then much easier for me to take a new position or even the reverse position and move on. > Not to repeat myself from an earlier post, but any pretense that > Python's primary objective is readability went out the window with the > invention of such constructs as "__del__", "__repr__", and > "super(MyClass, self).__init__()". There are obviously other goals to > the language's development that inspired these constructs and override > the priority of readability. No one said (that I know of) that readability is *the primary objective*. But it is a very important guideline. >> Here's an alternative test. Write a program to remove all the end of line >> colons from pythons library and then write another separate program to put >> them >> back in. Will it miss any? will it pass the python test suite? >> > I just may take you up on that. ;-) Not for a few days, though. Not > enough time right now. > > - Mike I believe you will find that exercise much more difficult than it seems, but I may be wrong. Good luck if you try it, and let me know how it goes. Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
[EMAIL PROTECTED] wrote: > > I'm not sure why '\'s are required to do multi-line before the > colon. > Special cases aren't special enough to break the rules. > > Georg > >>> A bit of a circular answer. > >>> > >>> Why the rule? -> So not to break the rule? > >> > >> You proposed to allow leaving off line continuation '\' only in the > >> "if", "for" and "while" headers. This is a special case in my eyes. > > Ron> I wasn't that specific and it was related to Michael's suggestion > Ron> the colon wasn't needed. If the need for '\' was dropped in > Ron> multi-line block headers, then the colon would be required for an > Ron> obvious reason. > > But \ is used to continue all sorts of statements/expressions, e.g.: > > x = a + \ > b > > not just conditionals. > > Skip Of course, and your point is? How about if it be ok to continue to use '\' in headers, but it also be ok to not to? That would be the backward compatible way to change it. This doesn't answer the question I was asking, are there any situation where it would cause problems? And if so, that reason would be a good and explicit reason for not making such a change. Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Georg Brandl wrote: > Ron Adam wrote: >> Georg Brandl wrote: >>> Ron Adam wrote: >>>> Michael Hobbs wrote: >>>> >>>>> The same problem that is solved by not having to type parens around the >>>>> 'if' conditional, a la C and its derivatives. That is, it's unnecessary >>>>> typing to no good advantage, IMHO. I was coding in Ruby for several >>>>> months and got very comfortable with just typing the if conditional and >>>>> hitting return, without any extra syntax. When I came back to Python, I >>>>> found that I felt annoyed every time I typed the colon, since it >>>>> obviously isn't required. The FAQ says that the colon increases >>>>> readability, but I'm skeptical. The indentation seems to provide more >>>>> than enough of a visual clue as to where the if conditional ends. >>>> I'm not sure why '\'s are required to do multi-line before the colon. >>> Special cases aren't special enough to break the rules. >>> >>> Georg >> A bit of a circular answer. >> >> Why the rule? -> So not to break the rule? > > You proposed to allow leaving off line continuation '\' only in the > "if", "for" and "while" headers. This is a special case in my eyes. I wasn't that specific and it was related to Michael's suggestion the colon wasn't needed. If the need for '\' was dropped in multi-line block headers, then the colon would be required for an obvious reason. If the requirement for line continuations was omitted for "any" block header starting with a python keyword and ending with a colon, would it still be a special case? It would be a bit less explicit. Are there situations where you would want to explicitly limit a block header to just a single line because of some negative consequence? I'm asking more for just plain curiosity, and not suggesting this actually be changed. In practice I don't think its enough of a issue to warrant changing in python 2.x. Although it just may (coin toss here) be beneficial for python 3k if extended annotations are implemented. Ron >> I would guess this probably is more applicable in this case. >> >> Explicit is better than implicit. > > Of course, this always applies :) > > Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Georg Brandl wrote: > Ron Adam wrote: >> Michael Hobbs wrote: >> >>> The same problem that is solved by not having to type parens around the >>> 'if' conditional, a la C and its derivatives. That is, it's unnecessary >>> typing to no good advantage, IMHO. I was coding in Ruby for several >>> months and got very comfortable with just typing the if conditional and >>> hitting return, without any extra syntax. When I came back to Python, I >>> found that I felt annoyed every time I typed the colon, since it >>> obviously isn't required. The FAQ says that the colon increases >>> readability, but I'm skeptical. The indentation seems to provide more >>> than enough of a visual clue as to where the if conditional ends. >> I'm not sure why '\'s are required to do multi-line before the colon. > > Special cases aren't special enough to break the rules. > > Georg A bit of a circular answer. Why the rule? -> So not to break the rule? I would guess this probably is more applicable in this case. Explicit is better than implicit. Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Steven D'Aprano wrote: > On Sat, 11 Nov 2006 01:13:03 -0600, Ron Adam wrote: > >> Steven D'Aprano wrote: >>> On Fri, 10 Nov 2006 21:24:50 +0100, Bjoern Schliessmann wrote: >>> >>>> Marc 'BlackJack' Rintsch wrote: >>>> >>>>> No it doesn't -- look again at the example given above. It's >>>>> legal syntax in Python but doesn't have the semantics implied by >>>>> the example. >>>> Sorry, I don't understand -- what is the difference between the >>>> example as it is and the implied semantics of it? >>> Inform 6 "x == blue or red or yellow" is equivalent to the Python >>> >>> x == blue or x == red or x == yellow >> Maybe it should have been expressed as: >> >> x == (blue or red or yellow) > > > But that has very different semantics still -- since parentheses have the > highest priority, it means "evaluate (blue or red or yellow), then test if > x is equal to the result". > > It might be useful on occasion to have a construct for "x equals blue or > red or yellow" in the sense used by normal English or Inform 6. And, > funnily enough, Python has such a construct. You just have to write "in" > instead of ==, and use a tuple for the terms: > > x in (blue, red, yellow) > > Not hard to remember, and unambiguous. Yes, that is the correct best way to do it, of course. Funny thing is I tested a variation of the above version in a console and it seemed to work, which surprised me. Now I can't get it to work, . I don't know exactly what I typed in last night, so I can't figure out what subtle (or overlooked obvious) characteristics my test had which gave me the misleading results. Sigh. I did think it was kind of odd it (apparently) worked, which was why I phrased it as a suggestion. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Paul Boddie wrote: > Ron Adam wrote: >> PS. Rather than shav of on character her and ther in pythons programing >> languag, Lets remov all the silent leters from the english languag. That will >> sav thousands mor kestroks over a few yers. > > How about changing Python to support keywords and identifiers employing > the Initial Teaching Alphabet? > > http://en.wikipedia.org/wiki/Initial_Teaching_Alphabet > > ;-) > > Paul Thanks for the link. I haven't heard about ita before. As one who constantly struggles with spelling, I wouldn't be adverse to such a change. But of course that would not be the best way to promote python. Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Steven D'Aprano wrote: > On Fri, 10 Nov 2006 21:24:50 +0100, Bjoern Schliessmann wrote: > >> Marc 'BlackJack' Rintsch wrote: >> >>> No it doesn't -- look again at the example given above. It's >>> legal syntax in Python but doesn't have the semantics implied by >>> the example. >> Sorry, I don't understand -- what is the difference between the >> example as it is and the implied semantics of it? > > Inform 6 "x == blue or red or yellow" is equivalent to the Python > > x == blue or x == red or x == yellow Maybe it should have been expressed as: x == (blue or red or yellow) Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Michael Hobbs wrote: > Ron Adam wrote: >> It is also an outline form that frequently used in written languages. >> Something >> python tries to do, is to be readable as if it were written in plain >> language >> where it is practical to do so. So the colon/outline form makes a certain >> sense >> in that case as well. >> > That is perhaps the most convincing argument that I've heard so far. > Indeed, I often find myself writing out colons when writing pseudo-code > out on paper. The reason, however, is usually because my indents don't > quite line up as perfectly on paper as they do in an editor. The colons > provide a form of backup separation for when my columns start to get > sloppy. (Natural language is actually filled with such redundancies in > order to compensate for sloppy handwriting.) This backup function > obviously isn't needed when a computer is taking care of the layout. > > My final argument against the colons is to simply try programming in > Ruby for a while and then come back to Python. I think you'll find that > programming without the colons just simply feels more "natural". LOL, of course it would. I would expect that too after a suitable amount of 'brain washing', oops, I mean training and conditioning. ;-) The point is what is more natural to "read" with a minimum amount of explanation. I would think for most people who are learning programming for the first time, it is things that resemble things they already know. Such as outlining with colons. Leaving the colon out probably would feel more natural for writing once you get used to it. After all it is a bit less typing. But I don't think it would be the most readable choice for most people. It's probably a trade off, readability vs writability. Another python development guideline is to favor readability over writability on the presumption we tend to write code once, but read code many times. Here's an alternative test. Write a program to remove all the end of line colons from pythons library and then write another separate program to put them back in. Will it miss any? will it pass the python test suite? I think you will find that that is more complex than it sounds. Try writing colorizing routines for both versions? Which is easier? Cheers, Ron PS. Rather than shav of on character her and ther in pythons programing languag, Lets remov all the silent leters from the english languag. That will sav thousands mor kestroks over a few yers. I think if you try that for a few months and then switch back, you will find writing without the silent letters just feels more natural. ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Michael Hobbs wrote: > Ron Adam wrote: >> The faq also pointed out a technical reason for requiring the colon. It >> makes >> the underlying parser much easier to write and maintain. This shouldn't be >> taken to lightly in my opinion, because a simpler easer to maintain and more >> reliable python parser means development time can be spent improving the >> language in other areas instead of fixing parsing problems every time a new >> feature is added that might be used in a conditional expression. >> > Not to be too picky about it, but the FAQ was referring to editor > parsers, not the parser used by Python itself. The Python parser could > easily change its grammar to make the colon optional. Yes, hmm. I seem to remember (possibly falsely) of someone saying it did make pythons parser simpler. Oh well. Making it easier for third party tools and parser to parse is still worth while in my opinion. > I find the editor parsing excuse to be weak since most editors tend to > get hung up on Python code anyway, regardless of the colons. (Except for > the ones that are specifically written to support Python, or are > insanely programmable, like emacs.) In fact, I find that my editor > usually gets confused when it comes across colons in dictionary literals > or lambda expressions. If it just stuck to looking at the indentation, > instead of trying to play off syntax tricks, it would behave much better. My editor (GVIM) has the most trouble with long triple quoted strings. I could probably modify the script a bit and fix that though. I've never run into problems with colons. In another post on this thread you use an example of consistancy as a reason for not having the colon. But maybe sometimes there can be too much consistency, like when you want to differentiate something because they have different contextual meaning. xxx xxx: yyy yyy yyy yyy Here the colon indicates a difference or change in context. A test vs a procedure, or a grouping vs attributes, etc. I suppose you could also interpret it as meaning 'related to'. In a way this is carried over to dictionaries where a key is related to it's value. A range is related to the loop body, a test is related to the if body, etc... It is also an outline form that frequently used in written languages. Something python tries to do, is to be readable as if it were written in plain language where it is practical to do so. So the colon/outline form makes a certain sense in that case as well. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Py3K idea: why not drop the colon?
Michael Hobbs wrote: > The same problem that is solved by not having to type parens around the > 'if' conditional, a la C and its derivatives. That is, it's unnecessary > typing to no good advantage, IMHO. I was coding in Ruby for several > months and got very comfortable with just typing the if conditional and > hitting return, without any extra syntax. When I came back to Python, I > found that I felt annoyed every time I typed the colon, since it > obviously isn't required. The FAQ says that the colon increases > readability, but I'm skeptical. The indentation seems to provide more > than enough of a visual clue as to where the if conditional ends. I'm not sure why '\'s are required to do multi-line before the colon. Possibly because if multi-line conditional expressions are the norm, dropping a colon could result in valid (but incorrect) code instead of an error? The faq also pointed out a technical reason for requiring the colon. It makes the underlying parser much easier to write and maintain. This shouldn't be taken to lightly in my opinion, because a simpler easer to maintain and more reliable python parser means development time can be spent improving the language in other areas instead of fixing parsing problems every time a new feature is added that might be used in a conditional expression. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Style for modules with lots of constants
Neil Cerutti wrote:
> On 2006-11-01, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Neil Cerutti:
>>> scriptref = glk.fileref_create_by_prompt('Transcript+TextMode',
>>>'WriteAppend', 0)
>> That "+" sign seems useless. A space looks enough to me. The
>> functions can accept case-agnostic strings and ignore spaces
>> inside them. Example:
>> ('transcript textmode ', 'writeappend', 0)
>
> That's pretty cool. Not as pretty, but easier for users,
> possibly.
>
>>> Parsing the combinable bitfield contants might be slowish,
>>> though.
>> I think you have to test if this is true for your situation.
>> Management of interned strings is probably fast enough
>> (compared to the rest of things done by the Python interpreter)
>> for many purposes.
>
> Agreed. I meant I'd have to later test if it's were fast enough.
I've found using plain strings as flags has several advantages.
The value 'textmode' is always 'textmode', there is no dependency on a module
or
class being imported or initialized.
It avoids having to type namespace prefixes such as thismod.textmode, or
myclass.textmode or importing a bunch of values into global name space.
Strings comparisons in python are very fast.
The disadvantage is an invalid flag may pass silently unless you do some sort
of
validation which may slow things down a bit.
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Collate Module
I've made a few more changes to my little collate module.
There might be better ways to handle the options, or better choices for the
options themselves. I tried to keep it as general as possible.
I think it should work with Unicode now too.
Any suggestions in making it faster will be appreciated.
Any minor improvements to wording, spelling, etc.. are also welcome.
Many thanks for all the terrific feed back and suggestions!
Cheers,
Ron
---start---
"""
Collate.py - Sorts lists of strings in various ways depending
options and locale.
Class: Collate(option_string)
Functions:
collate(text, option_string) -> collate in place
result = collated(text, option_string) -> get a collated copy
To use collate with your user locale you need to call setlocale()
before collating:
locale.setlocale(locale.LC_ALL, '')
This will set several global variables such as string
constants, time and monitary formats, as well as numerical
formatting to your user Locale. Instead of '', you can also
specify a specific locale.
The setttings can be restored back to the default 'C' locale with
the following:
locale.setlocale(locale.LC_ALL, 'C')
Example:
locale.setlocale(locale.LC_ALL, '')
tlist = [ 'Fruit', 'fruit-apple', 'fruit-bannana',
'nut-pecan', 'Nut' ]
collate(tlist, 'caps_first hyphen_as_space')
* For more examples see doctests in function test().
Author: Ron Adam, [EMAIL PROTECTED]
"""
import re
import locale
import string
__version__ = '0.03 (pre-alpha) 10/23/2006'
class Collate(object):
""" A general purpose collator class.
Use: collate(text, option_string)
result = collated(text, option_string)
text = a list of strings
opton_string = a string of space separated options.
Collation can be modified with the following options:
CAPS_FIRST -> Aaa, aaa, Bbb, bbb
LOWERCASE_FIRST -> aaa, Aaa, bbb, Bbb
HYPHEN_AS_SPACE -> hyphens separate words
PERIOD_AS_SPACE -> Periods separate numerals
NUMERICAL -> Digit sequences as numerals
IGNORE_COMMAS -> Allows commas in numerals
UNDERSCORE_AS_SPACE -> Underscore as white space
IGNORE_LEADING_WS -> Disregard leading white space
"""
options = ( 'CAPS_FIRST', 'LOWERCASE_FIRST', 'NUMERICAL',
'HYPHEN_AS_SPACE', 'UNDERSCORE_AS_SPACE',
'IGNORE_LEADING_WS', 'IGNORE_COMMAS', 'PERIOD_AS_SPACE' )
def __init__(self, flags=""):
locale_conv = locale.localeconv()
self.encoding = locale.getpreferredencoding()
self.dpoint = locale_conv['decimal_point']
self.thsep = locale_conv['thousands_sep']
pattern = ''.join([r'([\d\\', self.dpoint, r']*|\D*)'])
self.numrex = re.compile(pattern, re.LOCALE)
if flags:
flags = flags.upper().split()
for value in flags:
if value not in self.options:
raise ValueError, 'Invalid option: %s' % value
txtable = []
if 'HYPHEN_AS_SPACE' in flags:
txtable.append(('-', ' '))
if 'UNDERSCORE_AS_SPACE' in flags:
txtable.append(('_', ' '))
if 'PERIOD_AS_SPACE' in flags:
txtable.append(('.', ' '))
if 'IGNORE_COMMAS' in flags:
txtable.append((',', ''))
self.txtable = txtable
self.capsfirst = (
sorted(['A','a'], key=locale.strxfrm) == ['A', 'a']
)
self.flags = flags
def transform(self, s):
""" Transform a string for collating.
"""
if type(s) is unicode:
s = s.encode(self.encoding, 'replace')
if not self.flags:
return locale.strxfrm(s)
for a, b in self.txtable:
s = s.replace(a, b)
if 'IGNORE_LEADING_WS' in self.flags:
s = s.lstrip()
if 'CAPS_FIRST' in self.flags and not self.capsfirst:
s = s.swapcase()
if 'LOWERCASE_FIRST' in self.flags and self.capsfirst:
s = s.swapcase()
Re: PSF Infrastructure has chosen Roundup as the issue tracker for Python development
Kay Schluehr wrote: > Anna Ravenscroft wrote: > >> Interestingly enough, the quote of the day from Google on this email was: >> >> Never doubt that a small group of thoughtful, committed citizens can >> change the world; indeed, it's the only thing that ever has. >> Margaret Mead > > Commitment. Some individuals do the actual changes but others have to > commit to make these changes effective. I've no indication in human > history that groups are innovative or that they produce anything > compelling new. Sometimes they support ventilation or being busy with > "conservative innovation" or other oxymoronic activities. They serve a > critical function but are most of the time uncritical to themselves and > critical to everything and everyone else who is not using their own > code(s). Identifying the enemy is still the prime function of the > political and politics is all about groups. In this simple social > scheme the "hero" indicates the border. The hero acts outside of the > order of the group/society but the society uses the hero to indicate > its own interior in some kind of hegelian twist: the hero is the > otherness defining the self. The hero is the radical other supporting > the groups identify. At best the hero becomes the prince/souvereign of > the group and the group identifies itself as its knights. So the whole > truth about "changing the world" might be just slightly more complex. Committees often do fit this description. Of course, this is a subject that is very dependent on viewpoints. The world changes. Sometimes those changes are the result of certain events where groups of people were present. Sometimes individuals in the group had a significant effect on the outcome of those events. Sometimes the individuals were committed to a common purpose. Sometimes they were aided by sharing information and effort to achieve that purpose. Sometimes the outcome was one that is very unlikely or impossible for a single individual to have produced. It is this last point that is important. Sometimes groups are formed with the desire of reproducing this last point. Sometimes they succeed. There is also the view point of informal groups of individuals working separately but having a significant combined effect. This is probably the more common situation. But not as common as the viewpoint you've stated above unfortunately. Cheers, Ron > Never thought having a small philosophical conversion with Margaret > Mead beyond time and space. So many thanks to great Google and its > devotees. > > Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: invert or reverse a string... warning this is a rant
Steven D'Aprano wrote: > On Sat, 21 Oct 2006 01:58:33 -0500, Ron Adam wrote: > >> [You said from an earlier post...] >> >>> (That's a complaint I have about the dis module -- it prints its results, >>> instead of returning them as a string. That makes it hard to capture the >>> output for further analysis.) >> I have a rewritten version of dis just sitting on my hard disk that fixes >> exactly that issue. It needs to be updated to take into account some newer >> 2.5 >> features and the tests will need to be updated so they retrieve dis's output >> instead of redirecting stdout. If you'd like to finish it up and submit it >> as a >> patch, I can forward it to you. It would be good to have a second set of >> eyes >> look at it also. > > I'm certainly willing to look at it; as far as submitting it as a patch, I > have no idea what the procedure is. Maybe we can find out together heh? :-) Sounds good to me. I email an attachment to you. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: invert or reverse a string... warning this is a rant
Steven D'Aprano wrote: > On Thu, 19 Oct 2006 20:07:27 -0400, Brad wrote: > >> Steven D'Aprano wrote: >> >>> Gah!!! That's *awful* in so many ways. >> Thanks... I'm used to hearing encouragement like that. After a while you >> begin to believe that everything you do will be awful, so why even >> bother trying? > > Well obviously I hit a sore point. I wrote a little hastily, and wasn't > quite as polite as I could have been -- but it is true, the function you > wrote isn't good: a seven line function with five problems with it. > > Your function was not at all Pythonic; but it isn't even good style for > any serious programming language I know of. I'm sorry if I came across as > abrasive, but I'm even sorrier that you can't take constructive criticism. > Some techniques are bad practice in any language. Steven, I think just took things a little out of context, and yes you were a bit overly harsh. But I've also read enough of your post to know you most likely did not mean any insult either. Brad's little reminder program was not meant to be actually used in a program as is of course, but was a small script for him to run so he could see what was happening visually. Yes, it could be improved on for that purpose too. But for what it's purpose is, does it really matter that much? It does what he meant it to do. Yes, a small dose of politeness, (tactfulness isn't quite the same as suger coating), always helps when pointing out where others can make improvements especially while they are still learning their way around. With that said, If it were me who wrote something that you really thought was bad, then blast away! ;) (without insulting me of course.) I'd probably take a second look and agree with you. But I've been programming python since version 2.3 and as a more experienced programmer will appreciate the honest feed back. [You said from an earlier post...] > (That's a complaint I have about the dis module -- it prints its results, > instead of returning them as a string. That makes it hard to capture the > output for further analysis.) I have a rewritten version of dis just sitting on my hard disk that fixes exactly that issue. It needs to be updated to take into account some newer 2.5 features and the tests will need to be updated so they retrieve dis's output instead of redirecting stdout. If you'd like to finish it up and submit it as a patch, I can forward it to you. It would be good to have a second set of eyes look at it also. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Flexible Collating (feedback please)
Leo Kislov wrote: > Ron Adam wrote: >> Leo Kislov wrote: >>> Ron Adam wrote: >>> >>>> locale.setlocale(locale.LC_ALL, '') # use current locale settings >>> It's not current locale settings, it's user's locale settings. >>> Application can actually use something else and you will overwrite >>> that. You can also affect (unexpectedly to the application) >>> time.strftime() and C extensions. So you should move this call into the >>> _test() function and put explanation into the documentation that >>> application should call locale.setlocale >> I'll experiment with this a bit, I was under the impression that >> local.strxfrm >> needed the locale set for it to work correctly. > > Actually locale.strxfrm and all other functions in locale module work > as designed: they work in C locale before the first call to > locale.setlocale. This is by design, call to locale.setlocale should be > done by an application, not by a 3rd party module like your collation > module. Yes, I've come to that conclusion also. (reserching as I go) ;-) I put an example of that in the class doc string so it could easily be found. >> Maybe it would be better to have two (or more) versions? A string, unicode, >> and >> locale version or maybe add an option to __init__ to choose the behavior? > > I don't think it should be two separate versions. Unicode support is > only a matter of code like this: > > # in the constructor > self.encoding = locale.getpreferredencoding() > > # class method > def strxfrm(self, s): > if type(s) is unicode: > return locale.strxfrm(s.encode(self.encoding,'replace') > return locale.strxfrm(s) > > and then instead of locale.strxfrm call self.strxfrm. And similar code > for locale.atof Thanks for the example. >> This was the reason for using locale.strxfrm. It should let it work with >> unicode >> strings from what I could figure out from the documents. >> >> Am I missing something? > > strxfrm works only with byte strings encoded in the system encoding. > > -- Leo Windows has an alternative function, wcxfrm. (wide character transform) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_strxfrm.2c_.wcsxfrm.asp But it's not exposed in Python. I could use ctypes to call it, but it would then be windows specific and I doubt it would even work as expected. Maybe a wcsxfrm patch would be good for Python 2.6? Python 3000 will probably need it anyway. I've made a few additional changes and will start a new thread after some more testing to get some additional feedback. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: invert or reverse a string... warning this is a rant
James Stroud wrote: > Of course, I think str.join can operate on iterators, as Paul Rubin > suggests: > > > print ''.join(reversed(x)) > > This latter approach still seems a little clunky, though. > > James Slices can be named so you could do... >>> reverser = slice(None, None, -1) >>> >>> 'abcdefg'[reverser] 'gfedcba' Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] a little about regex
Fulvio wrote:
> ***
> Your mail has been scanned by InterScan MSS.
> ***
>
>
> On Wednesday 18 October 2006 15:32, Ron Adam wrote:
>
>> |Instead of using two separate if's, Use an if - elif and be sure to test
>
> Thank you, Ron, for the input :)
> I'll examine also in this mode. Meanwhile I had faced the total disaster :)
> of
> deleting all my emails from all server ;(
> (I've saved them locally, luckly :) )
>
>> |It's not exactly clear on what output you are seeking. If you want 0 for
>> | not filtered and 1 for filtered, then look to Freds Hint.
>
> Actually the return code is like herein:
>
> if _filter(hdrs,allow,deny):
> # allow and deny are objects prepared by re.compile(pattern)
> _del(Num_of_Email)
>
> In short, it means unwanted to be deleted.
> And now the function is :
>
> def _filter(msg,al,dn):
> """ Filter try to classify a list of lines for a set of compiled
>
> patterns."""
> a = 0
> for hdrline in msg:
> # deny has the first priority and stop any further searching. Score
> 10
> #times
> if dn.search(hdrline): return len(msg) * 10
> if al.search(hdrline): return 0
> a += 1
> return a # it returns with a score of rejected matches or zero if none
I see, is this a cleanup script to remove the least wanted items?
The allow/deny caused me to think it was more along the lines of a white/black
list. Where as keep/discard would be terms more suitable to cleaning out items
already allowed.
Or is it a bit of both? Why the score?
Just curious, I don't think I have any suggestions that will help in any
specific ways.
I would think the allow(keep?) filters would always have priority over deny
filters.
> The patterns are taken from a configuration file. Those with Axx ='pattern'
> are allowing streams the others are Dxx to block under different criteria.
> Here they're :
>
> [Filters]
> A01 = ^From:.*\.it\b
> A02 = ^(To|Cc):.*frioio@
> A03 = ^(To|Cc):.*the_sting@
> A04 = ^(To|Cc):.*calm_me_or_die@
> A05 = ^(To|Cc):.*further@
> A06 = ^From:.*\.za\b
> D01 = ^From:.*\.co\.au\b
> D02 = ^Subject:.*\*\*\*SPAM\*\*\*
>
> *A bit of fake in order to get some privacy* :)
> I'm using configparser to fetch their value and they're are joint by :
>
> allow = re.compile('|'.join([k[1] for k in ifil if k[0] is 'a']))
> deny = re.compile('|'.join([k[1] for k in ifil if k[0] is 'd']))
>
> ifil is the input filter's section.
>
> At this point I suppose that I have realized the right thing, just I'm a bit
> curious to know if ithere's a better chance and realize a single regex
> compilation for all of the options.
I think keeping the allow filter seperate from the deny filter is good.
You might be able to merge the header lines and run the filters across the
whole
header at once instead of each line.
> Basically the program will work, in term of filtering as per config and
> sincronizing with local $HOME/Mail/trash (configurable path). This last
> option will remove emails on the server for those that are in the local
> trash.
> Todo = backup local and remote emails for those filtered as good.
> multithread to connect all server in parallel
> SSL for POP3 and IMAP4 as well
> Actually I've problem on issuing the command to imap server to flag "Deleted"
> the message which count as spam. I only know the message details but what
> is the correct command is a bit obscure, for me.
I can't help you here. Sorry.
> BTW whose Fred?
>
> F
Fredrik see...
news://news.cox.net:119/[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Flexable Collating (feedback please)
Gabriel Genellina wrote:
> At Wednesday 18/10/2006 21:36, Ron Adam wrote:
>> Maybe changing the CAPS_FIRST to REVERSE_CAPS_ORDER would do?
>
> At least it's a more accurate name.
> There is an indirect way: test locale.strcoll("A","a") and see how they
> get sorted. Then define options CAPS_FIRST, LOWER_FIRST accordingly. But
> maybe it's too much trouble...
I should of thought of that simple test. Thanks. :-)
That would work, and it's really not that much trouble. The actual test can be
done during importing. Maybe determining other useful values could be done at
that time as well.
>> > You should try to make this part a bit more generic. If you are
>> > concerned about locales, do not use "comma" explicitely. In other
>> > countries 10*100=1.000 - and 1,234 is a fraction between 1 and 2.
>>
>> See the most recent version of this I posted. It is a bit more generic.
>>
>>news://news.cox.net:119/[EMAIL PROTECTED]
>>
>> Maybe a 'comma_is_decimal' option?
>
> I'd prefer to use the 'decimal_point' and 'thousands_sep' from the
> locale information. That would be more coherent with the locale usage
> along your module.
Yes, it looks like I'll need to do this.
>> The term I've seen before is called natural ordering, but that is more
>> general
>> and can include date, roman numerals, as well as other type.
>
> Sometimes that's the hard part, finding a name which is concise,
> descriptive, and accurately reflects what the code does. A good name
> should make obvious what it is used for (being these option names, or
> class names, or method names...) but in this case it may be difficult to
> find a good one. So users will have to read the documentation (a good
> thing, anyway!)
I plan on making the doc strings a bit more informative so that help(collate)
will give meaningful information on it's options.
Cheers,
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Re: Flexible Collating (feedback please)
[EMAIL PROTECTED] wrote:
> Ron Adam:
>
> Insted of:
>
> def __init__(self, flags=[]):
> self.flags = flags
> self.numrex = re.compile(r'([\d\.]*|\D*)', re.LOCALE)
> self.txtable = []
> if HYPHEN_AS_SPACE in flags:
> self.txtable.append(('-', ' '))
> if UNDERSCORE_AS_SPACE in flags:
> self.txtable.append(('_', ' '))
> if PERIOD_AS_COMMAS in flags:
> self.txtable.append(('.', ','))
> if IGNORE_COMMAS in flags:
> self.txtable.append((',', ''))
> self.flags = flags
>
> I think using a not mutable flags default is safer, this is an
> alternative (NOT tested!):
>
> numrex = re.compile(r'[\d\.]* | \D*', re.LOCALE|re.VERBOSE)
> dflags = {"hyphen_as_space": ('-', ' '),
> "underscore_as_space": ('_', ' '),
> "period_as_commas": ('_', ' '),
> "ignore_commas": (',', ''),
> ...
>}
>
> def __init__(self, flags=()):
> self.flags = [fl.strip().lower() for fl in flags]
> self.txtable = []
> df = self.__class__.dflags
> for flag in self.flags:
> if flag in df:
> self.txtable.append(df[flag])
> ...
>
> This is just an idea, it surely has some problems that have to be
> fixed.
I think the 'if's are ok since there are only a few options that need to be
handled by them.
I'm still trying to determine what options are really needed. I can get the
thousand separator and decimal character from local.localconv() function. So
ignore_commas isn't needed I think. And maybe change period_as_commas to
period
_as_sep and then split on periods before comparing.
I also want it to issue exceptions when the Collate object is created if
invalid
options are specified. That makes finding problems much easier. The example
above doesn't do that, it accepts them silently. That was one of the reasons I
went to named constants at first.
How does this look?
numrex = re.compile(r'([\d\.]* | \D*)', re.LOCALE|re.VERBOSE)
options = ( 'CAPS_FIRST', 'NUMERICAL', 'HYPHEN_AS_SPACE',
'UNDERSCORE_AS_SPACE', 'IGNORE_LEADING_WS',
'IGNORE_COMMAS', 'PERIOD_AS_COMMAS' )
def __init__(self, flags=""):
if flags:
flags = flags.upper().split()
for value in flags:
if value not in self.options:
raise ValueError, 'Invalid option: %s' % value
self.txtable = []
if 'HYPHEN_AS_SPACE' in flags:
self.txtable.append(('-', ' '))
if 'UNDERSCORE_AS_SPACE' in flags:
self.txtable.append(('_', ' '))
if 'PERIOD_AS_COMMAS' in flags:
self.txtable.append(('.', ','))
if 'IGNORE_COMMAS' in flags:
self.txtable.append((',', ''))
self.flags = flags
So you can set an option strings as...
import collate as C
collateopts = \
""" caps_first
hyphen_as_space
numerical
ignore_commas
"""
colatedlist = C.collated(somelist, collateopts)
A nice advantage with an option string is you don't have to prepend all your
options with the module name. But you do have to validate it.
Cheers,
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Re: Flexible Collating (feedback please)
Leo Kislov wrote: > Ron Adam wrote: > >> locale.setlocale(locale.LC_ALL, '') # use current locale settings > > It's not current locale settings, it's user's locale settings. > Application can actually use something else and you will overwrite > that. You can also affect (unexpectedly to the application) > time.strftime() and C extensions. So you should move this call into the > _test() function and put explanation into the documentation that > application should call locale.setlocale I'll experiment with this a bit, I was under the impression that local.strxfrm needed the locale set for it to work correctly. Maybe it would be better to have two (or more) versions? A string, unicode, and locale version or maybe add an option to __init__ to choose the behavior? Multiple versions seems to be the approach of pre-py3k. Although I was trying to avoid that. Sigh, of course issues like this is why it is better to have a module to do this with. If it was as simple as just calling sort() I wouldn't have bothered. ;-) >> self.numrex = re.compile(r'([\d\.]*|\D*)', re.LOCALE) > > [snip] > >> if NUMERICAL in self.flags: >> slist = self.numrex.split(s) >> for i, x in enumerate(slist): >> try: >> slist[i] = float(x) >> except: >> slist[i] = locale.strxfrm(x) > > I think you should call locale.atof instead of float, since you call > re.compile with re.LOCALE. I think you are correct, but it seems locale.atof() is a *lot* slower than float(). :( Here's the local.atof() code. def atof(string,func=float): "Parses a string as a float according to the locale settings." #First, get rid of the grouping ts = localeconv()['thousands_sep'] if ts: string = string.replace(ts, '') #next, replace the decimal point with a dot dd = localeconv()['decimal_point'] if dd: string = string.replace(dd, '.') #finally, parse the string return func(string) I could set ts and dd in __init__ and just do the replacements in the try... if NUMERICAL in self.flags: slist = self.numrex.split(s) for i, x in enumerate(slist): if x: # slist may contain null strings if self.ts: xx = x.replace(self.ts, '') # remove thousands sep if self.dd: xx = xx.replace(self.dd, '.') # replace decimal point try: slist[i] = float(xx) except: slist[i] = locale.strxfrm(x) How does that look? It needs a fast way to determine if x is a number or a string. Any suggestions? > Everything else looks fine. The biggest missing piece is support for > unicode strings. This was the reason for using locale.strxfrm. It should let it work with unicode strings from what I could figure out from the documents. Am I missing something? Thanks, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Flexable Collating (feedback please)
Gabriel Genellina wrote:
> At Wednesday 18/10/2006 03:42, Ron Adam wrote:
>
>> I put together the following module today and would like some feedback
>> on any
>> obvious problems. Or even opinions of weather or not it is a good
>> approach.
>> if self.flag & CAPS_FIRST:
>> s = s.swapcase()
>
> This is just coincidental; it relies on (lowercase)<(uppercase) on the
> locale collating sequence, and I don't see why it should be always so.
The LC_COLLATE structure (in the python.exe C code I think) controls the order
of upper and lower case during collating. I don't know if there is anyway to
examine it unfortunately.
If there was a way to change the LC_COLLATE structure, I wouldn't need to
resort
to tricks like s.swapcase(). But without that info, I don't know of another
way.
Maybe changing the CAPS_FIRST to REVERSE_CAPS_ORDER would do?
>> if self.flag & IGNORE_LEADING_WS:
>> s = s.strip()
I'm not sure if this would make any visible difference. It might determine
order
of two strings where they are the same, but one has white space at the end the
other doesn't.
They run at the same speed either way, so I'll go ahead and change it. Thanks.
> This ignores trailing ws too. (lstrip?)
>
>> if self.flag & NUMERICAL:
>> if self.flag & COMMA_IN_NUMERALS:
>> rex =
>> re.compile('^(\d*\,?\d*\.?\d*)(\D*)(\d*\,?\d*\.?\d*)',
>> re.LOCALE)
>> else:
>> rex = re.compile('^(\d*\.?\d*)(\D*)(\d*\.?\d*)',
>> re.LOCALE)
>> slist = rex.split(s)
>> for i, x in enumerate(slist):
>> if self.flag & COMMA_IN_NUMERALS:
>> x = x.replace(',', '')
>> try:
>> slist[i] = float(x)
>> except:
>> slist[i] = locale.strxfrm(x)
>> return slist
>> return locale.strxfrm(s)
>
> You should try to make this part a bit more generic. If you are
> concerned about locales, do not use "comma" explicitely. In other
> countries 10*100=1.000 - and 1,234 is a fraction between 1 and 2.
See the most recent version of this I posted. It is a bit more generic.
news://news.cox.net:119/[EMAIL PROTECTED]
Maybe a 'comma_is_decimal' option?
Options are cheep so it's no problem to add them as long as they make sense. ;-)
These options are what I refer to as mid-level options. The programmer does
still need to know something about the data they are collating. They may still
need to do some preprocessing even with this, but maybe not as much.
In a higher level collation routine, I think you would just need to specify a
named sort type, such as 'dictionary', 'directory', 'enventory' and it would
set
the options and accordingly. The problem with that approach is the higher
level
definitions may be different depending on locale or even the field it is used
in.
>> The NUMERICAL option orders leading and trailing digits as numerals.
>>
>> >>> t = ['a5', 'a40', '4abc', '20abc', 'a10.2', '13.5b', 'b2']
>> >>> collated(t, NUMERICAL)
>> ['4abc', '13.5b', '20abc', 'a5', 'a10.2', 'a40', 'b2']
>
> From the name "NUMERICAL" I would expect this sorting: b2, 4abc, a5,
> a10.2, 13.5b, 20abc, a40 (that is, sorting as numbers only).
> Maybe GROUP_NUMBERS... but I dont like that too much either...
How about 'VALUE_ORDERING' ?
The term I've seen before is called natural ordering, but that is more general
and can include date, roman numerals, as well as other type.
Cheers,
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Re: Flexable Collating (feedback please)
This is how I changed it...
(I edited out the test and imports for posting here.)
locale.setlocale(locale.LC_ALL, '') # use current locale settings
class Collate(object):
""" A general purpose and configurable collator class.
"""
options = [ 'CAPS_FIRST', 'NUMERICAL', 'HYPHEN_AS_SPACE',
'UNDERSCORE_AS_SPACE', 'IGNORE_LEADING_WS',
'IGNORE_COMMAS', 'PERIOD_AS_COMMAS' ]
def __init__(self, flags=""):
if flags:
flags = flags.upper().split()
for value in flags:
if value not in self.options:
raise ValueError, 'Invalid option: %s' % value
self.txtable = []
if 'HYPHEN_AS_SPACE' in flags:
self.txtable.append(('-', ' '))
if 'UNDERSCORE_AS_SPACE' in flags:
self.txtable.append(('_', ' '))
if 'PERIOD_AS_COMMAS' in flags:
self.txtable.append(('.', ','))
if 'IGNORE_COMMAS' in flags:
self.txtable.append((',', ''))
self.flags = flags
self.numrex = re.compile(r'([\d\.]*|\D*)', re.LOCALE)
def transform(self, s):
""" Transform a string for collating.
"""
if not self.flags:
return locale.strxfrm(s)
for a, b in self.txtable:
s = s.replace(a, b)
if 'IGNORE_LEADING_WS' in self.flags:
s = s.strip()
if 'CAPS_FIRST' in self.flags:
s = s.swapcase()
if 'NUMERICAL' in self.flags:
slist = self.numrex.split(s)
for i, x in enumerate(slist):
try:
slist[i] = float(x)
except:
slist[i] = locale.strxfrm(x)
return slist
return locale.strxfrm(s)
def __call__(self, a):
""" This allows the Collate class to be used as a sort key.
USE: list.sort(key=Collate(flags))
"""
return self.transform(a)
def collate(slist, flags=[]):
""" Collate list of strings in place.
"""
slist.sort(key=Collate(flags).transform)
def collated(slist, flags=[]):
""" Return a collated list of strings.
"""
return sorted(slist, key=Collate(flags).transform)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Flexable Collating (feedback please)
Thanks, But I fixed it already. (almost) ;-)
I think I will use strings as you suggest, and verify they are valid so a type
don't go though silently.
I ended up using string based option list. I agree a space separated string is
better and easier from a user point of view.
The advantage of the list is it can be iterated without splitting first. But
that's a minor thing. self.options = options.lower().split(' ') fixes that
easily.
Once I'm sure it's not going to get any major changes I'll post this as a
recipe. I think it's almost there.
Cheers and thanks,
Ron
[EMAIL PROTECTED] wrote:
> This part of code uses integer "constants" to be or-ed (or added):
>
> CAPS_FIRST = 1
> NUMERICAL = 2
> HYPHEN_AS_SPACE = 4
> UNDERSCORE_AS_SPACE = 8
> IGNORE_LEADING_WS = 16
> COMMA_IN_NUMERALS = 32
>
> ...
>
> def __init__(self, flag):
> self.flag = flag
> def transform(self, s):
> """ Transform a string for collating.
> """
> if self.flag & CAPS_FIRST:
> s = s.swapcase()
> if self.flag & HYPHEN_AS_SPACE:
> s = s.replace('-', ' ')
> if self.flag & UNDERSCORE_AS_SPACE:
> s = s.replace('_', ' ')
> if self.flag & IGNORE_LEADING_WS:
> s = s.strip()
> if self.flag & NUMERICAL:
> if self.flag & COMMA_IN_NUMERALS:
>
> This is used in C, but maybe for Python other solutions may be better.
> I can see some different (untested) solutions:
>
> 1)
>
> def selfassign(self, locals):
> # Code from web.py, modified.
> for key, value in locals.iteritems():
> if key != 'self':
> setattr(self, key, value)
>
> def __init__(self,
> caps_first=False,
> hyphen_as_space=False,
> underscore_as_space=False,
> ignore_leading_ws=False,
> numerical=False,
> comma_in_numerals=False):
> selfassign(self, locals())
>
> def transform(self, s):
> if self.caps_first:
> ...
>
> Disadvangages: if a flag is added/modified, the code has to be modified
> in two places.
>
>
> 2)
>
> def __init__(self, **kwds):
> self.lflags = [k for k,v in kwds.items() if v]
> def transform(self, s):
> if "caps_first" in self.lflags:
> ...
>
> This class can be created with 1 instead of Trues, to shorten the code.
>
> Disadvantages: the user of this class has to read from the class
> doctring or from from the docs the list of possible flags (and such
> docs can be out of sync from the code).
>
>
> 3)
>
> Tkinter (Tcl) shows that sometimes strings are better than int
> constants (like using "left" instead of tkinter.LEFT, etc), so this is
> another possibile solution:
I think maybe this is better, but I need to verify the flags so typos don't go
though silently.
> def __init__(self, flags=""):
> self.lflags = flags.lower().split()
> def transform(self, s):
> if "caps_first" in self.lflags:
> ...
>
> An example of calling this class:
>
> ... = Collate("caps_first hyphen_as_space numerical")
>
> I like this third (nonstandard) solution enough.
>
> Bye,
> bearophile
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: Flexible Collating (feedback please)
I made a number of changes ... (the new version is listed below)
These changes also resulted in improving the speed by about 3 times when all
flags are specified.
Collating now takes about 1/3 (or less) time. Although it is still quite a bit
slower than a bare list.sort(), that is to be expected as collate is locale
aware and does additional transformations on the data which you would need to
do
anyways. The tests where done with Unicode strings as well.
Changed the flag types from integer values to a list of named strings. The
reason for this is it makes finding errors easier and you can examine the flags
attribute and get a readable list of flags.
A better regular expression for separating numerals. It now separates numerals
in the middle of the string.
Changed flag COMMA_IN_NUMERALS to IGNORE_COMMAS, This was how it was
implemented.
Added flag PERIOD_AS_COMMAS
This lets you collate decimal separated numbers correctly such as version
numbers and internet address's. It also prevents numerals from being
interpreted as floating point or decimal.
It might make more since to implement it as PERIOD_IS_SEPARATOR. Needed?
Other minor changes to doc strings and tests were made.
Any feedback is welcome.
Cheers,
Ron
"""
Collate.py
A general purpose configurable collate module.
Collation can be modified with the following keywords:
CAPS_FIRST -> Aaa, aaa, Bbb, bbb
HYPHEN_AS_SPACE -> Don't ignore hyphens
UNDERSCORE_AS_SPACE -> Underscores as white space
IGNORE_LEADING_WS -> Disregard leading white space
NUMERICAL -> Digit sequences as numerals
IGNORE_COMMAS -> Allow commas in numerals
PERIOD_AS_COMMAS-> Periods can separate numerals.
* See doctests for examples.
Author: Ron Adam, [EMAIL PROTECTED]
"""
__version__ = '0.02 (pre-alpha) 10/18/2006'
import re
import locale
import string
locale.setlocale(locale.LC_ALL, '') # use current locale settings
# The above line may change the string constants from the string
# module. This may have unintended effects if your program
# assumes they are always the ascii defaults.
CAPS_FIRST = 'CAPS_FIRST'
HYPHEN_AS_SPACE = 'HYPHEN_AS_SPACE'
UNDERSCORE_AS_SPACE = 'UNDERSCORE_AS_SPACE'
IGNORE_LEADING_WS = 'IGNORE_LEADING_WS'
NUMERICAL = 'NUMERICAL'
IGNORE_COMMAS = 'IGNORE_COMMAS'
PERIOD_AS_COMMAS = 'PERIOD_AS_COMMAS'
class Collate(object):
""" A general purpose and configurable collator class.
"""
def __init__(self, flags=[]):
self.flags = flags
self.numrex = re.compile(r'([\d\.]*|\D*)', re.LOCALE)
self.txtable = []
if HYPHEN_AS_SPACE in flags:
self.txtable.append(('-', ' '))
if UNDERSCORE_AS_SPACE in flags:
self.txtable.append(('_', ' '))
if PERIOD_AS_COMMAS in flags:
self.txtable.append(('.', ','))
if IGNORE_COMMAS in flags:
self.txtable.append((',', ''))
self.flags = flags
def transform(self, s):
""" Transform a string for collating.
"""
if not self.flags:
return locale.strxfrm(s)
for a, b in self.txtable:
s = s.replace(a, b)
if IGNORE_LEADING_WS in self.flags:
s = s.strip()
if CAPS_FIRST in self.flags:
s = s.swapcase()
if NUMERICAL in self.flags:
slist = self.numrex.split(s)
for i, x in enumerate(slist):
try:
slist[i] = float(x)
except:
slist[i] = locale.strxfrm(x)
return slist
return locale.strxfrm(s)
def __call__(self, a):
""" This allows the Collate class work as a sort key.
USE: list.sort(key=Collate(flags))
"""
return self.transform(a)
def collate(slist, flags=[]):
""" Collate list of strings in place.
"""
slist.sort(key=Collate(flags).transform)
def collated(slist, flags=[]):
""" Return a collated list of strings.
"""
return sorted(slist, key=Collate(flags).transform)
def _test():
"""
DOC TESTS AND EXAMPLES:
Sort (and sorted) normally order all words beginning with caps
before all words beginning with lower case.
>>> t = ['tuesday', 'Tuesday', 'Monday', 'monday']
>>> sorted(t) # regular sort
['Monday&
Re: Flexable Collating (feedback please)
[EMAIL PROTECTED] wrote: > > On Oct 18, 2:42 am, Ron Adam <[EMAIL PROTECTED]> wrote: >> I put together the following module today and would like some feedback on any >> obvious problems. Or even opinions of weather or not it is a good approach. > ,,, > def __call__(self, a, b): > """ This allows the Collate class work as a sort key. > > USE: list.sort(key=Collate(flags)) > """ > return cmp(self.transform(a), self.transform(b)) > > You document _call__ as useful for the "key" keyword to sort, but you > implement it for the "cmp" keyword. The "key" allows much better > performance, since it's called only once per value. Maybe just : > return self.transform(a) > > -- George > Thanks, I changed it to the following... def __call__(self, a): """ This allows the Collate class work as a sort key. USE: list.sort(key=Collate(flags)) """ return self.transform(a) And also changed the sort call here ... def collate(slist, flags=0): """ Collate list of strings in place. """ slist.sort(key=Collate(flags)) <<< Today I'll do some performance tests to see how much faster it is for moderate sized lists. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: How to convert this list to string?
Jia Lu wrote:
> Hi all
>
> I have a list like:
>
list
> [1, 2, 3]
list[1:]
> [2, 3]
>
> I want to get a string "2 3"
>
str(list[1:])
> '[2, 3]'
>
> How can I do that ?
>
> thanks
Just to be different from the other suggestions...
>>> a = [1, 2, 3]
>>> str(a[1:]).strip('[]').replace(',', '')
'2 3'
By the way. It's a good idea to try not to use 'list' or other built-in names
for your own objects. Best to start with good habits so that you avoid odd
hard
to find bugs later.
Cheers,
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Re: [OT] a little about regex
Fulvio wrote:
> ***
> Your mail has been scanned by InterScan MSS.
> ***
>
>
> Hello,
>
> I'm trying to get working an assertion which filter address from some domain
> but if it's prefixed by '.com'.
> Even trying to put the result in a negate test I can't get the wanted result.
>
> The tought in program term :
>
def filter(adr):
> ... import re
> ... allow = re.compile('.*\.my(>|$)')
> ... deny = re.compile('.*\.com\.my(>|$)')
> ... cnt = 0
> ... if deny.search(adr): cnt += 1
> ... if allow.search(adr): cnt += 1
> ... return cnt
> ...
filter('[EMAIL PROTECTED]')
> 2
filter('[EMAIL PROTECTED]')
> 1
>
> Seem that I miss some better regex implementation to avoid that both of the
> filters taking action. I'm thinking of lookbehind (negative or positive)
> option, but I think I couldn't realize it yet.
> I think the compilation should either allow have no '.com' before '.my' or
> deny should have _only_ '.com' before '.my'. Sorry I don't get the correct
> sintax to do it.
>
> Suggestions are welcome.
>
> F
Instead of using two separate if's, Use an if - elif and be sure to test the
narrower filter first. (You have them in the correct order) That way it will
skip the more general filter and not increment cnt twice.
It's not exactly clear on what output you are seeking. If you want 0 for not
filtered and 1 for filtered, then look to Freds Hint.
Or are you writing a test at the moment, a 1 means it only passed one filter so
you know your filters are working as designed?
Another approach would be to assign values for filtered, accepted, and
undefined
and set those accordingly instead of incrementing and decrementing a counter.
Cheers,
Ron
--
http://mail.python.org/mailman/listinfo/python-list
Re: Flexable Collating (feedback please)
Fixed... Changed the collate() function to return None the same as sort() since it is an in place collate. A comment in _test() doctests was reversed. CAPS_FIRST option puts words beginning with capitals before, not after, words beginning with lower case of the same letter. It seems I always find a few obvious glitches right after I post something. ;-) Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Flexable Collating (feedback please)
I put together the following module today and would like some feedback on any
obvious problems. Or even opinions of weather or not it is a good approach.
While collating is not a difficult thing to do for experienced programmers, I
have seen quite a lot of poorly sorted lists in commercial applications, so it
seems it would be good to have an easy to use ready made API for collating.
I tried to make this both easy to use and flexible. My first thoughts was to
try and target actual uses such as Phone directory sorting, or Library sorting,
etc., but it seemed using keywords to alter the behavior is both easier and
more
flexible.
I think the regular expressions I used to parse leading and trailing numerals
could be improved. They work, but you will probably get inconsistent results if
the strings are not well formed. Any suggestions on this would be appreciated.
Should I try to extend it to cover dates and currency sorting? Probably those
types should be converted before sorting, but maybe sometimes it's useful
not to?
Another variation is collating dewy decimal strings. It should be easy to add
if someone thinks that might be useful.
I haven't tested this in *anything* yet, so don't plug it into production code
of any type. I also haven't done any performance testing.
See the doc tests below for examples of how it's used.
Cheers,
Ron Adam
"""
Collate.py
A general purpose configurable collate module.
Collation can be modified with the following keywords:
CAPS_FIRST -> Aaa, aaa, Bbb, bbb
HYPHEN_AS_SPACE -> Don't ignore hyphens
UNDERSCORE_AS_SPACE -> Underscores as white space
IGNORE_LEADING_WS -> Disregard leading white space
NUMERICAL -> Digit sequences as numerals
COMMA_IN_NUMERALS -> Allow commas in numerals
* See doctests for examples.
Author: Ron Adam, [EMAIL PROTECTED], 10/18/2006
"""
import re
import locale
locale.setlocale(locale.LC_ALL, '') # use current locale settings
# The above line may change the string constants from the string
# module. This may have unintended effects if your program
# assumes they are always the ascii defaults.
CAPS_FIRST = 1
NUMERICAL = 2
HYPHEN_AS_SPACE = 4
UNDERSCORE_AS_SPACE = 8
IGNORE_LEADING_WS = 16
COMMA_IN_NUMERALS = 32
class Collate(object):
""" A general purpose and configurable collator class.
"""
def __init__(self, flag):
self.flag = flag
def transform(self, s):
""" Transform a string for collating.
"""
if self.flag & CAPS_FIRST:
s = s.swapcase()
if self.flag & HYPHEN_AS_SPACE:
s = s.replace('-', ' ')
if self.flag & UNDERSCORE_AS_SPACE:
s = s.replace('_', ' ')
if self.flag & IGNORE_LEADING_WS:
s = s.strip()
if self.flag & NUMERICAL:
if self.flag & COMMA_IN_NUMERALS:
rex = re.compile('^(\d*\,?\d*\.?\d*)(\D*)(\d*\,?\d*\.?\d*)',
re.LOCALE)
else:
rex = re.compile('^(\d*\.?\d*)(\D*)(\d*\.?\d*)', re.LOCALE)
slist = rex.split(s)
for i, x in enumerate(slist):
if self.flag & COMMA_IN_NUMERALS:
x = x.replace(',', '')
try:
slist[i] = float(x)
except:
slist[i] = locale.strxfrm(x)
return slist
return locale.strxfrm(s)
def __call__(self, a, b):
""" This allows the Collate class work as a sort key.
USE: list.sort(key=Collate(flags))
"""
return cmp(self.transform(a), self.transform(b))
def collate(slist, flags=0):
""" Collate list of strings in place.
"""
return slist.sort(Collate(flags))
def collated(slist, flags=0):
""" Return a collated list of strings.
This is a decorate-undecorate collate.
"""
collator = Collate(flags)
dd = [(collator.transform(x), x) for x in slist]
dd.sort()
return list([B for (A, B) in dd])
def _test():
"""
DOC TESTS AND EXAMPLES:
Sort (and sorted) normally order all words beginning with caps
before all words beginning with lower case.
>>> t = ['tuesday', 'Tuesday', 'Monday', 'monday']
>>> sorted(t) # regular sort
['Monday', 'Tuesday', 'monday', 'tuesday']
Locale collation puts words beginning with
Re: Need a strange sort method...
Ron Adam wrote: > Neil Cerutti wrote: >> On 2006-10-16, Tim Chase <[EMAIL PROTECTED]> wrote: >>> If you need it in a flat list, rather than as a list of >>> chunk_size lists (which are handy for iterating over in many >>> cases), there are ways of obtaining it, such as the hackish >>> >>>>>> sum([a[i::chunk_size] for i in range(chunk_size)], []) >>> [1, 4, 7, 10, 2, 5, 8, 3, 6, 9] >>> >>> There are likely good recipes for flattening a list. I just >>> happen not to have any at my fingertips. >> >> Actually, there isn't a good recipe in Python for flattening a >> list. They all come out tasting like Circus Peanuts (Turkish >> Delight for you non-Yanks). >> > > > Here's two that I came up with. They are both very fast compared to > anything else I've seen. Maybe they won't taste so much like Peanuts. > :-) > > > def flatten(L): > """ Flatten a list in place. > """ > i = 0 > while i < len(L): > while type(L[i]) is list: > L[i:i+1] = L[i] > i += 1 > return L > > def sflatten(sequence): > """ Return a flattened sequence as a list. > """ > def iterinner(seq): > for s in seq: > if hasattr(s, '__iter__'): > for i in iterinner(s): > yield i > else: > yield s > return list(iterinner(sequence)) Woops, cut the wrong one... Replace sflatten above with the following. def flattened(seq): """ Return a flattened sequence as a list. """ def visit(a, x): for i in x: if not hasattr(i, '__iter__'): a.append(i) else: visit(a, i) a = [] visit(a, seq) return a > > Cheers, >Ron Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Need a strange sort method...
Neil Cerutti wrote: > On 2006-10-16, Tim Chase <[EMAIL PROTECTED]> wrote: >> If you need it in a flat list, rather than as a list of >> chunk_size lists (which are handy for iterating over in many >> cases), there are ways of obtaining it, such as the hackish >> >>>>> sum([a[i::chunk_size] for i in range(chunk_size)], []) >> [1, 4, 7, 10, 2, 5, 8, 3, 6, 9] >> >> There are likely good recipes for flattening a list. I just >> happen not to have any at my fingertips. > > Actually, there isn't a good recipe in Python for flattening a > list. They all come out tasting like Circus Peanuts (Turkish > Delight for you non-Yanks). > Here's two that I came up with. They are both very fast compared to anything else I've seen. Maybe they won't taste so much like Peanuts. :-) def flatten(L): """ Flatten a list in place. """ i = 0 while i < len(L): while type(L[i]) is list: L[i:i+1] = L[i] i += 1 return L def sflatten(sequence): """ Return a flattened sequence as a list. """ def iterinner(seq): for s in seq: if hasattr(s, '__iter__'): for i in iterinner(s): yield i else: yield s return list(iterinner(sequence)) Cheers, Ron Adam -- http://mail.python.org/mailman/listinfo/python-list
Re: Alphabetical sorts
Neil Cerutti wrote: > On 2006-10-17, Ron Adam <[EMAIL PROTECTED]> wrote: >> Neil Cerutti wrote: >>> On 2006-10-16, Ron Adam <[EMAIL PROTECTED]> wrote: >>>> I have several applications where I want to sort lists in >>>> alphabetical order. Most examples of sorting usually sort on >>>> the ord() order of the character set as an approximation. >>>> But that is not always what you want. >>> Check out strxfrm in the locale module. >> It looks to me this would be a good candidate for a >> configurable class. Something preferably in the string module >> where it could be found easier. >> >> Is there anyway to change the behavior of strxfrm or strcoll? >> For example have caps before lowercase, instead of after? > > You can probably get away with writing a strxfrm function that > spits out numbers that fit your definition of sorting. Since that function is 'C' coded in the builtin _locale, it can't be modified by python code. Looking around some more I found the documentation for the corresponding C functions and data structures. It looks like python may just wrap these. http://opengroup.org/onlinepubs/007908799/xbd/locale.html Here's one example of how to rewrite the Unicode collate in python. http://jtauber.com/blog/2006/01 I haven't tried changing it's behavior, but I did notice it treats words with hyphen in them differently than strxfrm. Here's one way to change caps order. a = ["Neil", "Cerutti", "neil", "cerutti"] locale.setlocale(locale.LC_ALL, '') tmp = [x.swapcase() for x in a] tmp.sort(key=locale.strxfrm) tmp = [x.swapcase() for x in tmp] print tmp ['Cerutti', 'cerutti', 'Neil', 'neil'] Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Alphabetical sorts
Neil Cerutti wrote: > On 2006-10-16, Ron Adam <[EMAIL PROTECTED]> wrote: >> I have several applications where I want to sort lists in >> alphabetical order. Most examples of sorting usually sort on >> the ord() order of the character set as an approximation. But >> that is not always what you want. > > Check out strxfrm in the locale module. > >>>> a = ["Neil", "Cerutti", "neil", "cerutti"] >>>> a.sort() >>>> a > ['Cerutti', 'Neil', 'cerutti', 'neil'] >>>> import locale >>>> locale.setlocale(locale.LC_ALL, '') > 'English_United States.1252' >>>> a.sort(key=locale.strxfrm) >>>> a > ['cerutti', 'Cerutti', 'neil', 'Neil'] Thanks, that helps. The documentation for local.strxfrm() certainly could be more complete. And the name isn't intuitive at all. It also coorisponds to the C funciton for translating strings which isn't the same thing. For that matter locale.strcoll() isn't documented any better. I see this is actually a very complex subject. A littler searching, found the following link on Wikipedia. http://en.wikipedia.org/wiki/Alphabetical_order#Compound_words_and_special_characters And from there a very informative report: http://www.unicode.org/unicode/reports/tr10/ It looks to me this would be a good candidate for a configurable class. Something preferably in the string module where it could be found easier. Is there anyway to change the behavior of strxfrm or strcoll? For example have caps before lowercase, instead of after? Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Alphabetical sorts
I have several applications where I want to sort lists in alphabetical order. Most examples of sorting usually sort on the ord() order of the character set as an approximation. But that is not always what you want. The solution of converting everything to lowercase or uppercase is closer, but it would be nice if capitalized words come before lowercase words of the same spellings. And I suspect ord() order may not be correct for some character sets. So I'm wandering what others have done and weather there is something in the standard library I haven't found for doing this. Below is my current way of doing it, but I think it can probably be improved quite a bit. This partial solution also allows ignoring leading characters such as spaces, tabs, and underscores by specifying what not to ignore. So '__ABC__' will be next to 'ABC'. But this aspect isn't my main concern. Maybe some sort of alphabetical order string could be easily referenced for various alphabets instead of having to create them manually? Also it would be nice if strings with multiple words were ordered correctly. Cheers, _Ron def stripto(s, goodchrs): """ Removes leading and trailing characters from string s which are not in the string goodchrs. """ badchrs = set(s) for c in goodchrs: if c in badchrs: badchrs.remove(c) badchrs = ''.join(badchrs) return s.strip(badchrs) def alpha_sorted(seq): """ Sort a list of strings in 123AaBbCc... order. """ order = ( '0123456789AaBbCcDdEeFfGgHhIiJjKkLlMmNn' 'OoPpQqRrSsTtUuVvWwXxYyZz' ) def chr_index(value, sortorder): """ Make a sortable numeric list """ result = [] for c in stripto(value, order): cindex = sortorder.find(c) if cindex == -1: cindex = len(sortorder)+ord(c) result.append(cindex) return result deco = [(chr_index(a, order), a) for a in seq] deco.sort() return list(x[1] for x in deco) -- http://mail.python.org/mailman/listinfo/python-list
Re: 3D Vector Type Line-Drawing Program
Scott David Daniels wrote: > Ron Adam wrote: >> Scott David Daniels wrote: >>> James Stroud wrote: >>>>> I'm looking for a program to do line-drawings in 3d, with output to >>>>> postscript or svg or pdf, etc. I would like to describe a scene >>>>> with certain 1-3d elements oriented in 3d space with dashed or >>>>> colored lines and filled or transparent surfaces (or maybe >>>>> semitransparent). >>> >>> >>> Take a look at VPython -- easy to start, 3-D display (wall-eye / >>> cross-eye) easy to run on. >> >> I really like VPython because of how easy it is to use once you are >> familiar with it. >> >> Is there a way to have the display show a wire frame image instead of >> shaded shapes? > You can draw the edges as lines. Is there a setting for this?, or are you suggesting reading the coordinates and creating curve objects for the edges? >> Is there an easy way to convert a display to something that can be >> printed? > > You can generate POV-ray source. This is not a system for creating > beautiful pictures, but rather a great 3-D sketch pad. Doing a little googling found this... http://cgkit.sourceforge.net/index.html Still most of the items listed here are geared more towards 3d animation or for generating displays and are not ideal for generating high quality printed pages. _Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: 3D Vector Type Line-Drawing Program
Scott David Daniels wrote: > James Stroud wrote: >>> I'm looking for a program to do line-drawings in 3d, with output to >>> postscript or svg or pdf, etc. I would like to describe a scene with >>> certain 1-3d elements oriented in 3d space with dashed or colored >>> lines and filled or transparent surfaces (or maybe semitransparent). > > > Take a look at VPython -- easy to start, 3-D display (wall-eye / > cross-eye) easy to run on. I really like VPython because of how easy it is to use once you are familiar with it. Is there a way to have the display show a wire frame image instead of shaded shapes? And with or without hidden line removal? Is there an easy way to convert a display to something that can be printed? Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Painless way to do 3D visualization
Peter Beattie wrote: > Hey folks, > > I need to do the following relatively simple 3D programming: > > I want to convert data from four-item tuples into 3D co-ordinates in a > regular tetrahedron. Co-ordinates come in sequences of 10 to 20, and the > individual dots in the tetrahedron need to be connected into > discontinuous lines. A single tetrahedron should contain at least two, > possibly more, such lines. I would like to show certain similarities in > the sequences/lines, eg by changing color, thickness, or maybe attaching > indeces to certain points in a particular sequence. > > I'd welcome suggestions as to what might be the most painless way to > achieve this in Python. So far, I've only tinkered a little with > VPython, but the lack of any decent documentation has proved to be a > major turn-off. > > TIA! What exactly are the four-items in the tuples? I think this is what you need along with an example... http://www.vpython.org/webdoc/visual/curve.html from visual import * # a simple polygon points = [(0,0,0),(0,1,0),(1,1,0),(1,0,0),(0,0,0)] curve(pos=points, color=color.red) # a polygon as separate segments grouped together in a frame. square2 = frame() points = [(0,0,1),(0,1,1),(1,1,1),(1,0,1),(0,0,1)] for i in xrange(len(points)-1): curve(frame=square2, pos=[points[i],points[i+1]], color=color.blue) square2.objects[2].color = color.green # change a line segments color square2.objects[2].radius = .02 # change a line segments thickness # looking at objects after they are made. print square2 print dir(square2) print square2.objects print dir(square2.objects[0]) -- http://mail.python.org/mailman/listinfo/python-list
Re: OO on python real life tutorial?
filippo wrote: > Hello, > > I coded my +10k lines app using Perl/Tk. It is something like a hotel > software manager, it has a bunch of windows to manage the arrivals, > bills etc etc. I want to port this on Python/WxPython but I'd like to > get benefit of python, not just doing a row by row raw porting. > > My problem is that I cannot figure out how OO could be useful in my > case. Is there a OO tutorial out there to help me? > > Thanks, > > Filippo One of the nice things about python is you can easily mix 00 and structured programming styles together as you need. I would also suggest separating you data structures which can either be in 00 or structured tables from your interface. The interface can definitely benefit from being in OO. If you tie your data too tightly to your interface, it will make maintaining and or switching interfaces later a lot harder. So you will have two groups of OO structures One for your data and one for your interface, and those can be in separate files. I don't know much about hotel management, but you might have a table of records, where each table object is a room, or area, that is a group of stuff to be managed together. Your data structures would be along the line of... (Very roughly to give you an idea of where you might start.) class record(object): attributes to store info about an object needing to be managed. ... class table(object): list of records that consist of an "area of responsibility" to be managed together such as the items in a room. ... methods to add, remove, get, and search table. ... class hoteldata(object): list of tables ... methods to add, remove, get, search tables. ... methods to generate report and graph data, but not methods to display such data, those would be in the interface group. Each record may consist of the individual things in that area. Where an area is "an area of responsibility" that is to be assigned to an individual and or needs to be handled together. And your interface OO structures would then consist of your widgets, windows, and forms you need in order to view, add, update, and delete records. It may not be too difficult to reorganize your current program into one of this type as you will probably just be regrouping many of your functions into class's to handle your records and tables. This is more of an accounting approach where you are using OO to model lists and records, and not a simulation where you would use OO to actually model the objects which can also work, but is much harder to do. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Easy Validators
Sometimes it's good to check things while working on them. This seems
like a good way to do that.
You could probably put these in a module and just import them.
from validators import *
I'm interested if anyone can think of ways to improve this further.
Each validator consists of an assertion with an error message if the
assertion fails.
The validator arguments can include an extra argument to check the
return value. Less than the number of arguments is ok. Any unspecified
arguments are not checked. Use Any to not check previous arguments in a
list. (see the examples at the end)
Cheers,
Ron
# - Some Simple Validators.
def Any(arg): pass
def IsNumber(arg):
assert type(arg) in (int, long, float), \
"%r is not a number" % arg
def IsInt(arg):
assert type(arg) in (int, long), \
"%r is not an Int" % arg
def IsFloat(arg):
assert isinstance(arg, float), \
"%r is not a flaot" % arg
def IsLong(arg):
assert isinstance(arg, long), \
"%r is not a long integer" % arg
def IsString(arg):
assert type(arg) in (str, unicode), \
"%r is not a string type" % arg
def InRange(start, stop):
def inrange(arg):
assert start <= arg <= stop, \
"%r is not in range %r through %r" % (arg, start, stop)
return inrange
def InSet(list_):
s = set(list_)
def inset(arg):
assert arg in s, \
"%r is not in %r" % (arg, s)
return inset
def LessThan(value):
def lessthan(arg):
assert arg < value, \
"%r is not less than %r." % (arg, value)
return lessthan
def MoreThan(value):
def morethan(arg):
assert arg > value, \
"%r is not more than %r." % (arg, value)
return morethan
def IsEven(arg):
assert arg % 2 == 0, \
"%r is not even" % arg
def IsOdd(arg):
assert arg % 2 == 1, \
"%r is not odd" % arg
def IsPositive(arg):
assert arg >= 0, \
"%r is not positive" % arg
def IsNegative(arg):
assert arg < 0, \
"%r is not negative" % arg
def IsTrue(arg):
assert arg is True, \
"%r is not True" % arg
def IsFalse(arg):
assert arg is False, \
"%r is not False" % arg
# - The validator decorator.
def validate(*types):
""" check arguments + return value against types given.
"""
def check_accepts(f):
def new_f(*args, **kwds):
assert len(types) <= len(args)+1, \
"Validators exceed arg count + return value."
for (a, t) in zip(args, types):
t(a)
result = f(*args, **kwds)
if len(types)>len(args):
types[-1](result)
return result
new_f.func_name = f.func_name
return new_f
return check_accepts
# -- Examples to play around with.
@validate(Any, IsInt, IsEven)
def add(a, b):
return a + b
@validate(InRange(1,6), InRange(1,6), LessThan(19))
def mul(a, b):
return a * b
# they stack too
@validate(IsInt, IsInt)
@validate(MoreThan(10),LessThan(10))
@validate(Any, IsPositive)
def sub(a, b):
return a - b
@validate(IsString, IsString)
def addstr(a, b):
return a + b
print add(3.0, 5)
print mul(3, 6)
print sub(11, 9)
print addstr('Hello ', 'World')
--
http://mail.python.org/mailman/listinfo/python-list
Re: String.digits help!!!
[EMAIL PROTECTED] wrote: > Simon Forman: > >> accessing it from a >> module (perhaps math.. math.infinity, math.epsilon, etc., just like >> math.pi and math.e.) > > It too looks acceptable. > > >> I look forward to hearing your thoughts an the subject. > > Thank you, but I am not expert enough on such topics to give you good > comments, so I keep the muzzle shut. > > Bye, > bearophile > I've been thinking along this lines as well, but with the more general question of when should a method or attribute be included in a type or class and when shouldn't it. I think that's an important question and having some clear guidelines for that will help me to write better programs in general. A few general rules I've found to be mostly true is.. (1) If a class method does not have a reference to 'self' or an attribute or other method of self. It probably should be a function instead. This is more common than you might think because class's are also used as containers to hold a collection of functions and/or values. I think its useful to keep these collections separate from "objects". It keeps the objects simpler, and the collection of functions and values clearer. The difficulty is when you mix the two together, that's when you begin to get a cluttered class that is difficult to understand. (2) If no method of a class has a reference to an attribute, then the attribute should probably not be part of the class or type. On the flip side, the inverse of these rules does not necessarily mean something should be in the class. But maybe... (3) If an value is not useful by other class's or functions. It probably should be an attribute of the class. These are just guide lines of course, but by keeping them in mind, I do think it has helped me to abstain from writing cluttered class's. Maybe there are other guidelines like these that are helpful? Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Fastest Way To Loop Through Every Pixel
Chaos wrote: > As my first attempt to loop through every pixel of an image, I used > > for thisY in range(0, thisHeight): > for thisX in range(0, thisWidth): > #Actions here for Pixel thisX, thisY > > But it takes 450-1000 milliseconds > > I want speeds less than 10 milliseconds > > I have tried using SWIG, and pypy but they all are unsuccessfull in > compiling my files. This probably won't work for you, but it's worth suggesting as it may give you other ideas to solve your problem. If it is a list of lists of pixel objects you can iterate though the pixels directly and not use range or xrange at all. For this to work the pixel object needs to be mutable or have an attribute to store it's value. It can't be just an int, in that case you will need to use indexes. pixel = [rgb_value] or pixel = [r,g,b] or class Pixel(object): def __self__(self, rgb_value): self.value = rgb_value pixel = Pixel(rgb_value) Or some other variation that is mutable. These may not be suitable and may cause additional overhead elsewhere as the image may need to be converted to some other form in order to display or save it. What Actions are you performing on the pixels? You may be able to increase the speed by creating lookup tables in dictionaries and then use the pixel value for the key. Just a rough example... action1 = dict() # fill dict with precomputed pixel key value pairs. # ... image = getimage() for row in image: for pixel in row: # one of the following or something similar pixel[0] = action1[pixel] pixel.value = action1[pixel.value] pixel[:] = action[pixel] The pixels need to be objects so they are mutable. If they aren't, then you will need to use index's as you did above. Precomputing the pixel value tables may use up too much memory or take a very long time if your image has a large amount of possible colors. If precomputing the pixels take too long but you are not concerned by the memory usage, you may be able to store (pickle) the precomputed tables then unpickle it before it is used. This work best if the number of colors (the depth) is limited. If these suggestions aren't applicable, then you most likely need to look at an image library that uses compiled C (or assembly) code to do the brute force work. It may also be possible to access your platforms directX or opengl library routines directly to do it. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: MS VC++ Toolkit 2003, where?
Alex Martelli wrote: > Ron Adam <[EMAIL PROTECTED]> wrote: >... >> I still get the following with the tinyurl link: >> >> ~~~ >> The download you requested is unavailable. If you continue to see this >> message when trying to access this download, go to the "Search for a >> Download" area on the Download Center home page. >> ~~~ >> >> >> Pasting the above tinyurl into firefox results in the following link. >> >> http://www.microsoft.com/downloads/details.aspx?familyid=272BE09D-40BB-4&d >> isplaylang=en >> >> Which appears to still be truncated. :-/ > > True, but here's the kicker: using the full URL, which I just dblchecked > from Rushby's original message as being (enclosing in <...>)...: Yes, I tried the full url also, but was hoping I did something wrong. Sigh... guess not. > <http://www.microsoft.com/downloads/details.aspx?FamilyId=272BE09D-40BB- > 49FD-9CB0-4BFA122FA91B&displaylang=en> > > NOW gives me the same error page too. When Rushby suggested it > yesterday I immediately used it, and it allowed me to download the > Toolkit 2003 just fine -- so, I guess Microsoft must have killed that > possibility shortly thereafter (who said they can't move fast?-). > > As of now, I don't know any more of a URL that's usable to download > this, therefore:-( And with a new version of windows due at the end of this year, it's likely those who upgrade to Vista, will also need to upgrade to visual studio 2005 or later. I've seen this pattern before. :-/ Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: MS VC++ Toolkit 2003, where?
Alex Martelli wrote: > "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > >> Alex Martelli wrote: >>> As suggested to me by David Rushby 10 hours ago, >>> >>> http://www.microsoft.com/downloads/details.aspx?FamilyId=272BE09D-40BB-4 >>> 9FD-9CB0-4BFA122FA91B&displaylang=en >>> >>> does work. >> Can you please try this again: I'm also getting the error message >> that AIM is getting. > > Try tinyurl http://tinyurl.com/gv8wr please. I still get the following with the tinyurl link: ~~~ The download you requested is unavailable. If you continue to see this message when trying to access this download, go to the "Search for a Download" area on the Download Center home page. ~~~ Pasting the above tinyurl into firefox results in the following link. http://www.microsoft.com/downloads/details.aspx?familyid=272BE09D-40BB-4&displaylang=en Which appears to still be truncated. :-/ > I've also tinyurl'd your URL for the 1.1 SDK, to > http://tinyurl.com/5flob . This one works. > ((I suspect the problem has to do with a limitation of 80 > characters/line in NNTP messages, which my favorite newsreader enforces > unconditionally)). > > Alex -- http://mail.python.org/mailman/listinfo/python-list
