Re: Using the Python Interpreter as a Reference

[Ian Kelly]

On Mon, Nov 28, 2011 at 7:42 PM, Travis Parks  wrote:
> I find that interesting. I also find it interesting that the common
> functional methods (all, any, map, filter) are basically built into
> Python core language. That is unusual for most imperative programming
> languages early-on.

all and any are actually quite recent additions.  Guido added them to
placate users of "reduce(lambda x, y: x and y, foo)" back when the
plan was to remove reduce in Python 3.

Cheers,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pragmatics of the standard is() function

[alex23]

On Nov 29, 5:22 am, Den  wrote:
> On Nov 26, 3:01 pm, Steven D'Aprano  > That is correct. You probably should rarely use `is`. Apart from testing
> > for None, use of `is` should be rare.
>
> With respect, I disagree with advice that the use of a language
> construct should be rare.  All constructs should be used
> *appropriately*.

Steven didn't say it _shouldn't_ be used, only that it it should be
_rarely_ used. General consensus would be that that is the most
appropriate use of 'is'.

Value comparisons are _far_ more common in Python than identity
comparisons, the ubiquitous None notwithstanding.

But for your general point, I totally agree. I feel the same way about
the ternary syntax, boolean defaults for conditionals etc
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 2.5 and ast

[Dave Angel]

On 11/28/2011 03:08 PM, Terry Reedy wrote:

On 11/28/2011 6:45 AM, Andrea Crotti wrote:

I'm happily using the ast module to analyze some code,
but my scripts need also to run unfortunately on python 2.5

The _ast was there already, but the ast helpers not yet.
Is it ok if I just copy over the source from the ast helpers in my code
base


That is the standard way of backporting features of later versions.

But don't forget to tag it as version specific, so it gets removed when 
the later version of the library is available.  There are various ways 
of doing that, but the easiest is probably to put a test in the 
acceptance suite that fails if this code is used in 2.6 or later.


--

DaveA

--
http://mail.python.org/mailman/listinfo/python-list

Re: Does py2app improves speed?

[Dave Angel]

On 11/28/2011 03:03 PM, Alan Meyer wrote:

On 11/24/2011 9:27 AM, Dave Angel wrote:
...

Several ways to speed up code.

1) use language features to best advantage
2) use 3rd party libraries that do certain things well
3) use best algorithms, subject to #1 and #2
4) have someone else review the code (perhaps on the list, perhaps
within your own organization)
5) measure (eg. profile it)
6) use optimizing tools, such as pypy or Cython.
7) rewrite parts of it in another language
8) get a faster processor
9) rewrite it all in another language

It takes experience to choose between these, and each project is
different. But even the most experienced developers will frequently
guess entirely wrong where the bottleneck is, which is why you measure
if you care.


I agree that measuring (profiling) is the most critical.

As you say, even the most experienced programmers can guess wrong.  
The first time I used a profiler a couple of decades ago I was 
egotistical enough to wonder how this thing could help me.  After all, 
I wrote the code.  I knew what it did.  The profiler wasn't going to 
tell me anything I didn't know.


I learned  a little humility after reading the profiler output.  The 
program was spending most of its time in a place that I never dreamed 
was a problem, and a 10 minute fix cut run times in half.


In that particular case there wasn't even a design problem, it was 
just a procedure call inside a tight loop that executed far more often 
than I imagined and could be replaced with a few lines of inline code.


I think the rest of your list is excellent too.

Alan


Thanks.  I once had an assignment to speed up a function implementation 
which was obviously slow (I had noted the same thing to the architect 
when I first saw the code;  it would definitely be slow on large data 
sets).  I knew faster algorithms.  But I stopped instead to measure how 
many times it was being called in the particularly slow scenario that 
the customer complained about.  Turns out it wasn't being called at 
all.  I asked the appropriate developer why he had chosen to do it 
another way (expecting he'd say because he knew this function was slow), 
and he gave me an entirely different reason.  I asked him whether he'd 
be willing to call this function if I fixed his complaint about its 
interface, and he agreed.


Now, I rewrote the function, making a change to tighten its interface 
restrictions.  And it cut the customer's wait time from 90 minutes to 
2.  Everyone was happy.


Total time spent, a week.  But I didn't start coding till the 4th day.


--

DaveA

--
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Travis Parks]

On Nov 28, 5:57 pm, Steven D'Aprano  wrote:
> On Mon, 28 Nov 2011 13:29:06 -0800, Travis Parks wrote:
> > Exception handling is one of those subjects few understand and fewer can
> > implement properly in modern code. Languages that don't support
> > exceptions as part of their signature lead to capturing generic
> > Exception all throughout code. It is one of those features I wish .NET
> > had. At the same time, with my limited experience with Java, it has been
> > a massive annoyance. Perhaps something to provide or just shut off via a
> > command line parameter. What indications have there been that this has
> > been a flaw? I can see it alienating a large group of up- and-coming
> > developers.
>
> http://www.ibm.com/developerworks/java/library/j-jtp05254/index.html
>
> Note also that Bruce Eckel repeats a rumour that checked exceptions were
> *literally* an experiment snuck into the Java language while James
> Gosling was away on holiday.
>
> http://www.mindview.net/Etc/Discussions/UnCheckedExceptionComments
>
> Even if that is not true, checked exceptions are a feature that *in
> practice* seems to lead to poor exception handling and cruft needed only
> to satisfy the compiler:
>
> http://www.alittlemadness.com/2008/03/12/checked-exceptions-failed-ex...
>
> and other annoyances. It's main appeal, it seems to me, is to give a
> false sense of security to Java developers who fail to realise that under
> certain circumstances Java will raise certain checked exceptions *even if
> they are not declared*. E.g. null pointer exceptions.
>
> See also:
>
> http://java.dzone.com/articles/checked-exceptions-i-love-you
>
> and note especially the comment from the coder who says that he simply
> declares his functions to throw Exception (the most generic checked
> exception), thus defeating the whole point of checked exceptions.
>
> --
> Steven

I think all of the examples you listed referred specifically to most
programmers finding ways around the annoyance. I have heard about
throwing generic Exception or inheriting all custom exception types
from RuntimeException. I did this quite often myself.

In general, unchecked exceptions shouldn't be caught. They occur
because of bad code and insufficient testing. Checked exceptions occur
because of downed databases, missing files, network problems - things
that may become available later without code changes.

One day, I went through about 10,000 lines of code and moved argument
checking code outside of try blocks because I realized I was handling
some of them by accident. Here is the program: if me == idiot: exit().

People don't think about this, but the exceptions thrown by a module
are part of that module's interface. Being able to make sure only what
you expect to come out is important. Unlike Java, Unit requires you to
opt in to using throws clauses. If you don't list one, one is
generated for you automatically. The benefit: you can see what a
function throws and protect yourself without all the babysitting.

A lack of exception handling is big problem in .NET. I have had
libraries from big names including Novell and Oracle throw
NullReferenceExceptions because _they_ didn't know what would happen
in cases where a DLL is missing or a dependency isn't installed. They
could have done better testing, but if the biggest names in
development can't manage to figure it, I say leave it up to the
compiler. Returning nulls or special value in cases of failures takes
us back to the days of C and Fortran.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Travis Parks]

On Nov 28, 8:49 pm, Chris Angelico  wrote:
> On Tue, Nov 29, 2011 at 11:54 AM, DevPlayer  wrote:
> > To me, I would think the interpreter finding the coder's intended
> > indent wouldn't be that hard. And just make the need for consistant
> > spaces or tabs irrevelent simply by reformatting the indent as
> > expected. Pretty much all my text editors can.
>
> The trouble with having a language declaration that "a tab is
> equivalent to X spaces" is that there's no consensus as to what X
> should be. Historically X has always been 8, and quite a few programs
> still assume this. I personally like 4. Some keep things narrow with
> 2. You can even go 1 - a strict substitution of \t with \x20. Once you
> declare it in your language, you immediately break everyone who uses
> anything different.
>
> ChrisA

Yeah. We must remember the Unix users, espcially those who don't know
how to hack Vim or bash. I've decided not to require a specific number
of spaces. I am still teetering on whether to allow tabs.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Chris Angelico]

On Tue, Nov 29, 2011 at 1:42 PM, Travis Parks  wrote:
> A good example I have run into is recursion. When a local function
> calls itself, the name of the function may not be part of scope (non-
> local). Languages that support tail-end recursion optimization can't
> optimize. In order to support this, a function in Unit will have
> access to its own name and type. In other words, special scoping rules
> are in place in Unit to allow treating a function as an expression.

I'm inclined toward an alternative: explicit recursion. Either a
different syntax, or a special-case on the use of the function's own
name, but whichever syntax you use, it compiles in a "recurse" opcode.
That way, if name bindings change, it's still going to recurse -
something few languages guarantee, and therefore few languages can
optimize.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Travis Parks]

On Nov 28, 5:24 pm, Steven D'Aprano  wrote:
> On Mon, 28 Nov 2011 12:32:59 -0700, Ian Kelly wrote:
> > On Sun, Nov 27, 2011 at 4:55 PM, Steven D'Aprano
> >  wrote:
> [...]
> >>> Lambdas and functions are the same thing in my language, so no need
> >>> for a special keyword.
>
> >> That does not follow. Lambdas and def functions are the same thing in
> >> Python, but Python requires a special keyword.
>
> > I think the implication is that Unit has only one syntax for creating
> > functions, which is lambda-style.  In any case, why does Python require
> > a special keyword?  def is only used in a statement context, and lambda
> > is only used in an expression context.  Why not use the same keyword for
> > both?
>
> Because the syntax is completely different. One is a statement, and
> stands alone, the other is an expression. Even putting aside the fact
> that lambda's body is an expression, and a def's body is a block, def
> also requires a name. Using the same keyword for both would require
> special case reasoning: sometimes def is followed by a name, sometimes
> without a name. That's ugly.
>
> def name(args): block  # okay
>
> funcs = [def args: expr,  # okay so far
>          def name(args): expr,  # not okay
>          def: expr,  # okay
>          ]
>
> def: expr  # also okay
>
> def: expr
>     expr  # but not okay
>
> x = def x: expr  # okay
> x = def x(x): expr  # not okay
>
> Using the same keyword for named and unnamed functions is, in my opinion,
> one of those foolish consistencies we are warned about. When deciding on
> syntax, the difference between anonymous and named functions are more
> significant than their similarities.

A good example I have run into is recursion. When a local function
calls itself, the name of the function may not be part of scope (non-
local). Languages that support tail-end recursion optimization can't
optimize. In order to support this, a function in Unit will have
access to its own name and type. In other words, special scoping rules
are in place in Unit to allow treating a function as an expression.

>
> > I think the answer is historical:  def came first, and when
> > anonymous functions were added it didn't make sense to use the keyword
> > "def" for them, because "def" implies a name being defined.
>
> That reasoning still applies even if they were added simultaneously.
>
> Lambda is pretty old: it certainly exists in Python 1.5 and almost
> certainly in 1.4. While it doesn't exist as a keyword in Python 0.9.1,
> there is a module called "lambda" with a function "lambda" that uses more
> or less the same syntax. Instead of lambda x: x+1, you would instead
> write lambda("x", "x+1"). So the idea of including anonymous functions
> was around in Python circles before the syntax was locked in.

I find that interesting. I also find it interesting that the common
functional methods (all, any, map, filter) are basically built into
Python core language. That is unusual for most imperative programming
languages early-on.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Chris Angelico]

On Tue, Nov 29, 2011 at 11:54 AM, DevPlayer  wrote:
> To me, I would think the interpreter finding the coder's intended
> indent wouldn't be that hard. And just make the need for consistant
> spaces or tabs irrevelent simply by reformatting the indent as
> expected. Pretty much all my text editors can.

The trouble with having a language declaration that "a tab is
equivalent to X spaces" is that there's no consensus as to what X
should be. Historically X has always been 8, and quite a few programs
still assume this. I personally like 4. Some keep things narrow with
2. You can even go 1 - a strict substitution of \t with \x20. Once you
declare it in your language, you immediately break everyone who uses
anything different.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[DevPlayer]

> I do not understand why the interpreter preprocesses each logical line
> of source code using something as simple as this:


correction:

I do not understand why the interpreter - does not- preprocess each
logical line
of source code using something as simple as this:
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[DevPlayer]

On Nov 27, 6:55 pm, Steven D'Aprano  wrote:
> On Sun, 27 Nov 2011 14:21:01 -0800, Travis Parks wrote:
> > Personally, I find a lot of good things in Python. I thinking tabs are
> > out-of-date. Even the MAKE community wishes that the need for tabs would
> > go away and many implementations have done just that.
>
> Tabs have every theoretical advantage and only one practical
> disadvantage: the common toolsets used by Unix programmers are crap in
> their handling of tabs, and instead of fixing the toolsets, they blame
> the tabs.
>
> The use of spaces as indentation is a clear case of a technically worse
> solution winning over a better solution.
>
> > I have been
> > seriously debating about whether to force a specific number of spaces,
> > such as the classic 4, but I am not sure yet. Some times, 2 or even 8
> > spaces is appropriate (although I'm not sure when).
>
> Why on earth should your language dictate the width of an indentation? I
> can understand that you might care that indents are consistent within a
> single source code unit (a file?), but anything more than that is just
> obnoxious.
>

I do not understand why the interpreter preprocesses each logical line
of source code using something as simple as this:

def reindent( line, spaces_per_tab=os.spaces_per_tab):

index = 0  # index into line of text
indent = 0 # increase 1 when in next tab column
spaces = 0 # index into current column

for c in line:
if c == ' ':
spaces +=1
if spaces >= spaces_per_tab:
indent += 1
spaces = 0
if c == '\t':   # jump to next tab column
indent += 1
spaces = 0
if c <> ' ' and c <> '\t':
break
index += 1
rest_of_line = line[index:]
new_indent = ' ' * indent * spaces_per_tab + ' ' * spaces
newline = new_indent + rest_of_line

return newline

or even some regex equivelent.

That function would need to be run on each line of source code, after
processing the line continuation character and single/double/triple
quote pairs are processed but before the code block tokenizer (INDENT/
DEDENT) if possible. Unless some of you expert parser/compiler writers
know fancier tricks.

To me, I would think the interpreter finding the coder's intended
indent wouldn't be that hard. And just make the need for consistant
spaces or tabs irrevelent simply by reformatting the indent as
expected. Pretty much all my text editors can.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Steven D'Aprano]

On Mon, 28 Nov 2011 13:29:06 -0800, Travis Parks wrote:

> Exception handling is one of those subjects few understand and fewer can
> implement properly in modern code. Languages that don't support
> exceptions as part of their signature lead to capturing generic
> Exception all throughout code. It is one of those features I wish .NET
> had. At the same time, with my limited experience with Java, it has been
> a massive annoyance. Perhaps something to provide or just shut off via a
> command line parameter. What indications have there been that this has
> been a flaw? I can see it alienating a large group of up- and-coming
> developers.

http://www.ibm.com/developerworks/java/library/j-jtp05254/index.html

Note also that Bruce Eckel repeats a rumour that checked exceptions were 
*literally* an experiment snuck into the Java language while James 
Gosling was away on holiday.

http://www.mindview.net/Etc/Discussions/UnCheckedExceptionComments

Even if that is not true, checked exceptions are a feature that *in 
practice* seems to lead to poor exception handling and cruft needed only 
to satisfy the compiler:

http://www.alittlemadness.com/2008/03/12/checked-exceptions-failed-experiment/#comment-219143

and other annoyances. It's main appeal, it seems to me, is to give a 
false sense of security to Java developers who fail to realise that under 
certain circumstances Java will raise certain checked exceptions *even if 
they are not declared*. E.g. null pointer exceptions.

See also:

http://java.dzone.com/articles/checked-exceptions-i-love-you

and note especially the comment from the coder who says that he simply 
declares his functions to throw Exception (the most generic checked 
exception), thus defeating the whole point of checked exceptions.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Chris Angelico]

On Tue, Nov 29, 2011 at 9:24 AM, Steven D'Aprano
 wrote:
> Because the syntax is completely different. One is a statement, and
> stands alone, the other is an expression. Even putting aside the fact
> that lambda's body is an expression, and a def's body is a block, def
> also requires a name. Using the same keyword for both would require
> special case reasoning: sometimes def is followed by a name, sometimes
> without a name. That's ugly.
>

All you need to do is define that a block of code is an object (and
thus suitable material for an expression), and you have easy
commonality.

fn = def(args):
block
of
code

Now def is an expression that takes an optional name (omitted in the
above), an arg list, and a block of code... and there's minimal
difference between named and anonymous functions. (If it's given a
name, then it sets __name__ and also binds to that name, being
convenient for the common case. The above code is a silly way to do
almost the default.)

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Steven D'Aprano]

On Mon, 28 Nov 2011 12:32:59 -0700, Ian Kelly wrote:

> On Sun, Nov 27, 2011 at 4:55 PM, Steven D'Aprano
>  wrote:
[...]
>>> Lambdas and functions are the same thing in my language, so no need
>>> for a special keyword.
>>
>> That does not follow. Lambdas and def functions are the same thing in
>> Python, but Python requires a special keyword.
> 
> I think the implication is that Unit has only one syntax for creating
> functions, which is lambda-style.  In any case, why does Python require
> a special keyword?  def is only used in a statement context, and lambda
> is only used in an expression context.  Why not use the same keyword for
> both?

Because the syntax is completely different. One is a statement, and 
stands alone, the other is an expression. Even putting aside the fact 
that lambda's body is an expression, and a def's body is a block, def 
also requires a name. Using the same keyword for both would require 
special case reasoning: sometimes def is followed by a name, sometimes 
without a name. That's ugly.

def name(args): block  # okay

funcs = [def args: expr,  # okay so far
 def name(args): expr,  # not okay
 def: expr,  # okay
 ]

def: expr  # also okay

def: expr
expr  # but not okay

x = def x: expr  # okay
x = def x(x): expr  # not okay

Using the same keyword for named and unnamed functions is, in my opinion, 
one of those foolish consistencies we are warned about. When deciding on 
syntax, the difference between anonymous and named functions are more 
significant than their similarities.


> I think the answer is historical:  def came first, and when
> anonymous functions were added it didn't make sense to use the keyword
> "def" for them, because "def" implies a name being defined.

That reasoning still applies even if they were added simultaneously.

Lambda is pretty old: it certainly exists in Python 1.5 and almost 
certainly in 1.4. While it doesn't exist as a keyword in Python 0.9.1, 
there is a module called "lambda" with a function "lambda" that uses more 
or less the same syntax. Instead of lambda x: x+1, you would instead 
write lambda("x", "x+1"). So the idea of including anonymous functions 
was around in Python circles before the syntax was locked in.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Chris Angelico]

On Tue, Nov 29, 2011 at 8:29 AM, Travis Parks  wrote:
> Languages that don't support
> exceptions as part of their signature lead to capturing generic
> Exception all throughout code. It is one of those features I wish .NET
> had. At the same time, with my limited experience with Java, it has
> been a massive annoyance.

In Java, it mainly feels like syntactic salt. There's still a class of
RuntimeExceptions that aren't listed in the signature, so you still
have to concern yourself with the possibility that unexpected
exceptions will propagate; and you're forced to decorate every method
with the list of what it might propagate up, other than that.

It's like const-decorating a series of functions in C++, only far less
consequential and requiring far more typing.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Cursor.fetchall

[Jean-Michel Pichavant]

Jean-Michel Pichavant wrote:


PS : Try to code & document in English, it's much better especially 
when asking for help on this list, mixing spanish and english has few 
benefits since you may bother both spanish and english ppl :o)
Actually it is english mixed with portuguese, sorry if I offended anyone 
:o( .


JM
--
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Travis Parks]

On Nov 28, 3:40 pm, Gregory Ewing  wrote:
> Travis Parks wrote:
> > I thinking tabs are
> > out-of-date. Even the MAKE community wishes that the need for tabs
> > would go away
>
> The situation with make is a bit different, because it
> *requires* tabs in certain places -- spaces won't do.
> Python lets you choose which to use as long as you don't
> mix them up, and I like it that way.
>
> > let Parse = public static method (value: String)
> > throws(FormatException UnderflowException OverflowException)
>
> Checked exceptions? I fear you're repeating a huge mistake
> going down that route...
>
> --
> Greg
>
>

Exception handling is one of those subjects few understand and fewer
can implement properly in modern code. Languages that don't support
exceptions as part of their signature lead to capturing generic
Exception all throughout code. It is one of those features I wish .NET
had. At the same time, with my limited experience with Java, it has
been a massive annoyance. Perhaps something to provide or just shut
off via a command line parameter. What indications have there been
that this has been a flaw? I can see it alienating a large group of up-
and-coming developers.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Travis Parks]

On Nov 28, 2:32 pm, Ian Kelly  wrote:
> On Sun, Nov 27, 2011 at 4:55 PM, Steven D'Aprano
>
>  wrote:
> >> My language combines generators and collection initializers, instead of
> >> creating a whole new syntax for comprehensions.
>
> >> [| for i in 0..10: for j in 0.10: yield return i * j |]
>
> > Are we supposed to intuit what that means?
>
> > Is | a token, or are the delimiters [| and |] ?
>
> > Is there a difference between iterating over 0..10 and iterating over
> > what looks like a float 0.10?
>
> > What is "yield return"?
>
> I would assume that "yield return" is borrowed from C#, where it is
> basically equivalent to Python's yield statement.  The advantage of
> using two keywords like that is that you can compare the statements
> "yield return foo" and "yield break", which is a bit clearer than
> comparing the equivalent "yield foo" and "return".
>
> Having to type out "yield return" in every comprehension seems a bit
> painful to me, but I can understand the approach: what is shown above
> is a full generator, not a single "generator expression" like we use
> in Python, so the statement keywords can't be omitted.  It's trading
> off convenience for expressiveness (a bad trade-off IMO -- complex
> generators should be named, not anonymous).
>
> >> Lambdas and functions are the same thing in my language, so no need for
> >> a special keyword.
>
> > That does not follow. Lambdas and def functions are the same thing in
> > Python, but Python requires a special keyword.
>
> I think the implication is that Unit has only one syntax for creating
> functions, which is lambda-style.  In any case, why does Python
> require a special keyword?  def is only used in a statement context,
> and lambda is only used in an expression context.  Why not use the
> same keyword for both?  I think the answer is historical:  def came
> first, and when anonymous functions were added it didn't make sense to
> use the keyword "def" for them, because "def" implies a name being
> defined.
>
> Cheers,
> Ian
>
>

Most languages I have worked with have a "lambda" syntax and a
function syntax. It has always been a historical artifact. Languages
start out avoiding functional features and then eventually adopt them.
It seems that eventually, convenient high-order functions become a
must-have (most standard algorithm packages). It is a conflict between
old C-style programming and the need for functional code. As soon as
functions can be assigned to variables, the code starts looking oddly
like JavaScript.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Neil Cerutti]

On 2011-11-28, Gregory Ewing  wrote:
> Neil Cerutti wrote:
>> I've always held with the "anti-functional style conspiracy"
>> interpretation of Python's lambda expressions. They were added
>> but grudgingingly, made weak on purpose to discourage their
>> use.
>
> Seems to me that Python's lambdas are about as powerful as they
> can be given the statement/expression distinction. No
> conspiracy is needed, just an understandable desire on Guido's
> part not to do violence to the overall syntactic style of the
> language.

It's true. Most conspiracy theories do fall apart once facts and
clear thinking are applied. But we love them anyway. ;)

-- 
Neil Cerutti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: remove characters before last occurance of "."

[plsullivan1]

Thanks!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: remove characters before last occurance of "."

[Arnaud Delobelle]

On 28 November 2011 20:45, Ethan Furman  wrote:
> plsulliv...@gmail.com wrote:
>>
>> s = GIS.GIS.Cadastral\GIS.GIS.Citylimit
>> NeededValue = Citylimit
>
> NeededValue = s.rsplit('.', 1)[1]

Also:

>>> s[s.rfind(".") + 1:]
'Citylimit'
>>> s.rpartition(".")[2]
'Citylimit'

-- 
Arnaud
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: remove characters before last occurance of "."

[Ethan Furman]

plsulliv...@gmail.com wrote:

s = GIS.GIS.Cadastral\GIS.GIS.Citylimit
NeededValue = Citylimit


NeededValue = s.rsplit('.', 1)[1]

~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Alemu mihretu]

Hello all,

My python runs and crashes after another run. I am getting errors like
Microsoft Visual C++ Runtime Library

program c:\Python27\pythonw.exe

This application has requested the Runtime to terminate it in an usuak way.
Please contact the application's support team for more information.

Any Idea ?

my plot also does not work ? frustrating


On Mon, Nov 28, 2011 at 12:32 PM, Ian Kelly  wrote:

> On Sun, Nov 27, 2011 at 4:55 PM, Steven D'Aprano
>  wrote:
> >> My language combines generators and collection initializers, instead of
> >> creating a whole new syntax for comprehensions.
> >>
> >> [| for i in 0..10: for j in 0.10: yield return i * j |]
> >
> > Are we supposed to intuit what that means?
> >
> > Is | a token, or are the delimiters [| and |] ?
> >
> > Is there a difference between iterating over 0..10 and iterating over
> > what looks like a float 0.10?
> >
> > What is "yield return"?
>
> I would assume that "yield return" is borrowed from C#, where it is
> basically equivalent to Python's yield statement.  The advantage of
> using two keywords like that is that you can compare the statements
> "yield return foo" and "yield break", which is a bit clearer than
> comparing the equivalent "yield foo" and "return".
>
> Having to type out "yield return" in every comprehension seems a bit
> painful to me, but I can understand the approach: what is shown above
> is a full generator, not a single "generator expression" like we use
> in Python, so the statement keywords can't be omitted.  It's trading
> off convenience for expressiveness (a bad trade-off IMO -- complex
> generators should be named, not anonymous).
>
> >> Lambdas and functions are the same thing in my language, so no need for
> >> a special keyword.
> >
> > That does not follow. Lambdas and def functions are the same thing in
> > Python, but Python requires a special keyword.
>
> I think the implication is that Unit has only one syntax for creating
> functions, which is lambda-style.  In any case, why does Python
> require a special keyword?  def is only used in a statement context,
> and lambda is only used in an expression context.  Why not use the
> same keyword for both?  I think the answer is historical:  def came
> first, and when anonymous functions were added it didn't make sense to
> use the keyword "def" for them, because "def" implies a name being
> defined.
>
> Cheers,
> Ian
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Gregory Ewing]

Neil Cerutti wrote:


I've always held with the "anti-functional style conspiracy"
interpretation of Python's lambda expressions. They were added
but grudgingingly, made weak on purpose to discourage their use.


Seems to me that Python's lambdas are about as powerful
as they can be given the statement/expression distinction.
No conspiracy is needed, just an understandable desire on
Guido's part not to do violence to the overall syntactic
style of the language.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Gregory Ewing]

Travis Parks wrote:

I thinking tabs are
out-of-date. Even the MAKE community wishes that the need for tabs
would go away


The situation with make is a bit different, because it
*requires* tabs in certain places -- spaces won't do.
Python lets you choose which to use as long as you don't
mix them up, and I like it that way.


let Parse = public static method (value: String)
throws(FormatException UnderflowException OverflowException)


Checked exceptions? I fear you're repeating a huge mistake
going down that route...

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Pragmatics of the standard is() function

[Ethan Furman]

Den wrote:

With respect, I disagree with advice that the use of a language
construct should be rare.  All constructs should be used
*appropriately*.


+1

~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

remove characters before last occurance of "."

[plsullivan1]

I need for GIS.GIS.Cadastral\GIS.GIS.Citylimit to be Citylimit. The "cadastral" 
and "citylimit" will be different as I readlines from a list. In other words, 
the above could be GIS.GIS.Restricted\GIS.GIS.Pipeline and I would need 
Pipeline.

s = GIS.GIS.Cadastral\GIS.GIS.Citylimit
NeededValue = Citylimit

Thanks.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Neil Cerutti]

On 2011-11-28, Ian Kelly  wrote:
> I think the implication is that Unit has only one syntax for
> creating functions, which is lambda-style.  In any case, why
> does Python require a special keyword?  def is only used in a
> statement context, and lambda is only used in an expression
> context.  Why not use the same keyword for both?  I think the
> answer is historical:  def came first, and when anonymous
> functions were added it didn't make sense to use the keyword
> "def" for them, because "def" implies a name being defined.

I've always held with the "anti-functional style conspiracy"
interpretation of Python's lambda expressions. They were added
but grudgingingly, made weak on purpose to discourage their use.

-- 
Neil Cerutti
  "This room is an illusion and is a trap devisut by Satan.  Go
ahead and dauntlessly!  Make rapid progres!"
  --Ghosts 'n Goblins
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 2.5 and ast

[Terry Reedy]

On 11/28/2011 6:45 AM, Andrea Crotti wrote:

I'm happily using the ast module to analyze some code,
but my scripts need also to run unfortunately on python 2.5

The _ast was there already, but the ast helpers not yet.
Is it ok if I just copy over the source from the ast helpers in my code
base


That is the standard way of backporting features of later versions.

--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: Does py2app improves speed?

[Alan Meyer]

On 11/24/2011 9:27 AM, Dave Angel wrote:
...

Several ways to speed up code.

1) use language features to best advantage
2) use 3rd party libraries that do certain things well
3) use best algorithms, subject to #1 and #2
4) have someone else review the code (perhaps on the list, perhaps
within your own organization)
5) measure (eg. profile it)
6) use optimizing tools, such as pypy or Cython.
7) rewrite parts of it in another language
8) get a faster processor
9) rewrite it all in another language

It takes experience to choose between these, and each project is
different. But even the most experienced developers will frequently
guess entirely wrong where the bottleneck is, which is why you measure
if you care.


I agree that measuring (profiling) is the most critical.

As you say, even the most experienced programmers can guess wrong.  The 
first time I used a profiler a couple of decades ago I was egotistical 
enough to wonder how this thing could help me.  After all, I wrote the 
code.  I knew what it did.  The profiler wasn't going to tell me 
anything I didn't know.


I learned  a little humility after reading the profiler output.  The 
program was spending most of its time in a place that I never dreamed 
was a problem, and a 10 minute fix cut run times in half.


In that particular case there wasn't even a design problem, it was just 
a procedure call inside a tight loop that executed far more often than I 
imagined and could be replaced with a few lines of inline code.


I think the rest of your list is excellent too.

Alan
--
http://mail.python.org/mailman/listinfo/python-list

Re: Pragmatics of the standard is() function

[Den]

On Nov 26, 3:01 pm, Steven D'Aprano  wrote:
> On Sat, 26 Nov 2011 22:20:36 +0100, candide wrote:
>>SNIP<<
>
> That is correct. You probably should rarely use `is`. Apart from testing
> for None, use of `is` should be rare.
>
> --
> Steven

With respect, I disagree with advice that the use of a language
construct should be rare.  All constructs should be used
*appropriately*.

While in general a particular use of a Python construct may be rare,
if the programmer is involved deeply with that rare use, then it is
NOT rare to him/her.  Thus, for a particular programmer, use of 'is'
may be quite frequent because the program they're working on requires
knowledge of object identity.

The same goes for global variables, by the way.  While it's easy to
shoot yourself in the foot with global variables, that doesn't lead to
never-use-them.  It leads to use-them-appropriately-and-carefully.

Sorry, you plucked a string of mine.  One does not throw a tool out of
your tool box because it might be dangerous.  Table saws are
incredibly dangerous, but in the hands of a skilled operator can be
competently and safely used to produce beautiful woodwork.  To say
*never* use a table saw because it's dangerous is silly.

Language constructs are put there intentionally.  Advice that they be
used *rarely* or *never* should *never* be given ((chuckle)).  Just
learn what they are, learn how they work, learn what the consequences
of misuse can be (loss of a hand, in the case of a table saw), and use
them confidently when the circumstances make them the best choice of
tool to solve your problem.

To make a long comment short (too late!!) learn the differences
between 'is' and ==, and use them appropriately.  When I was learning
Python, I found the two books by Mark Lutz to be filled with
information of such things as these.

D
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Ian Kelly]

On Sun, Nov 27, 2011 at 4:55 PM, Steven D'Aprano
 wrote:
>> My language combines generators and collection initializers, instead of
>> creating a whole new syntax for comprehensions.
>>
>> [| for i in 0..10: for j in 0.10: yield return i * j |]
>
> Are we supposed to intuit what that means?
>
> Is | a token, or are the delimiters [| and |] ?
>
> Is there a difference between iterating over 0..10 and iterating over
> what looks like a float 0.10?
>
> What is "yield return"?

I would assume that "yield return" is borrowed from C#, where it is
basically equivalent to Python's yield statement.  The advantage of
using two keywords like that is that you can compare the statements
"yield return foo" and "yield break", which is a bit clearer than
comparing the equivalent "yield foo" and "return".

Having to type out "yield return" in every comprehension seems a bit
painful to me, but I can understand the approach: what is shown above
is a full generator, not a single "generator expression" like we use
in Python, so the statement keywords can't be omitted.  It's trading
off convenience for expressiveness (a bad trade-off IMO -- complex
generators should be named, not anonymous).

>> Lambdas and functions are the same thing in my language, so no need for
>> a special keyword.
>
> That does not follow. Lambdas and def functions are the same thing in
> Python, but Python requires a special keyword.

I think the implication is that Unit has only one syntax for creating
functions, which is lambda-style.  In any case, why does Python
require a special keyword?  def is only used in a statement context,
and lambda is only used in an expression context.  Why not use the
same keyword for both?  I think the answer is historical:  def came
first, and when anonymous functions were added it didn't make sense to
use the keyword "def" for them, because "def" implies a name being
defined.

Cheers,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Return of an old friend

[Den]

On Nov 25, 2:13 am, Noah Hall  wrote:
> On Fri, Nov 25, 2011 at 5:08 AM, Matt Joiner  wrote:
> > I haven't heard of you before, but feel like I've missed out on something.
>
> > Do you (or someone else) care to link to some of your more contentious work?
>
> Ignore him, he's a troll with an unjustly inflated ego.

((laugh)) Well, that didn't take long.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: correct usage of a generator?

[Tim]

thanks everyone. I thought blarg.next() looked a little strange--I'm just 
learning generators now and I'm glad too see that next(blarg) is the way to go.

The example really was just a toy or I would use an iterator. I do need the two 
(well, the several) generators to not be coupled together so they increment 
independently. I'll keep the zero-padding advice in mind--I didn't think of 
that one.

what a great group this is. 
thanks again!
--Tim
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using the Python Interpreter as a Reference

[Travis Parks]

On Nov 27, 6:55 pm, Steven D'Aprano  wrote:
> On Sun, 27 Nov 2011 14:21:01 -0800, Travis Parks wrote:
> > Personally, I find a lot of good things in Python. I thinking tabs are
> > out-of-date. Even the MAKE community wishes that the need for tabs would
> > go away and many implementations have done just that.
>
> Tabs have every theoretical advantage and only one practical
> disadvantage: the common toolsets used by Unix programmers are crap in
> their handling of tabs, and instead of fixing the toolsets, they blame
> the tabs.
>
> The use of spaces as indentation is a clear case of a technically worse
> solution winning over a better solution.
>
> > I have been
> > seriously debating about whether to force a specific number of spaces,
> > such as the classic 4, but I am not sure yet. Some times, 2 or even 8
> > spaces is appropriate (although I'm not sure when).
>
> Why on earth should your language dictate the width of an indentation? I
> can understand that you might care that indents are consistent within a
> single source code unit (a file?), but anything more than that is just
> obnoxious.
>
> > I have always found the standard library for Python to be disjoint. That
> > can be really beneficial where it keeps the learning curve down and the
> > size of the standard modules down. At the same time, it means
> > re-learning whenever you use a new module.
>
> I know what disjoint means, but I don't understand what you think it
> means for a software library to be disjoint. I don't understand the rest
> of the paragraph.
>
> > My language combines generators and collection initializers, instead of
> > creating a whole new syntax for comprehensions.
>
> > [| for i in 0..10: for j in 0.10: yield return i * j |]
>
> Are we supposed to intuit what that means?
>
> Is | a token, or are the delimiters [| and |] ?
>
> Is there a difference between iterating over 0..10 and iterating over
> what looks like a float 0.10?
>
> What is "yield return"?
>
> > Lambdas and functions are the same thing in my language, so no need for
> > a special keyword.
>
> That does not follow. Lambdas and def functions are the same thing in
> Python, but Python requires a special keyword.
>
> > I also distinguish between initialization and
> > assignment via the let keyword.
>
> What does this mean? I can guess, but I might guess wrong.
>
> > Also, non-locals do not need to be
> > defined explicitly, since the scoping rules in Unit are far more "anal".
>
> What does this mean? I can't even guess what you consider more anal
> scoping rules.
>
> > In reality though, it takes a certain level of arrogance to assume that
> > any language will turn out without bumps. It is like I was told in
> > college long ago, "Only the smallest programs are bug free." I think the
> > same thing could be said for a language. The only language without flaws
> > would be so small that it would be useless.
>
> I'm pretty sure that being so small that it is useless would count as a
> flaw.
>
> What does it mean to say that a language is "small"?
>
> A Turing Machine is a pretty small language, with only a few
> instructions: step forward, step backwards, erase a cell, write a cell,
> branch on the state of the cell. And yet anything that can be computed,
> anything at all, can be computed by a Turning Machine: a Turing Machine
> can do anything you can do in C, Lisp, Fortran, Python, Java... and very
> probably anything you can (mentally) do, full stop. So what does that
> mean about "small" languages?
>
> On the other hand, take Epigram, a functional programming language:
>
> http://en.wikipedia.org/wiki/Epigram_(programming_language)
>
> It is *less* powerful than a Turing Machine, despite being far more
> complex. Similarly languages like regular expressions, finite automata
> and context-free grammers are more complex, "bigger", possibly with
> dozens or hundreds of instructions, and yet less powerful. Likewise for
> spreadsheets without cycles.
>
> Forth is much smaller than Java, but I would say that Forth is much, much
> more powerful in some sense than Java. You could write a Java compiler in
> Forth more easily than you could write a Forth compiler in Java.
>
> --
> Steven
>
>

Yes. I was mostly rambling. More explanation would have meant more
typing.

Languages that use type inference heavily typically find unique ways
of indicating literals, including numbers and collections. In Unit,
[||] indicates fixed length arrays, [] is for dynamic arrays, {} is
for sets and unordered dictionaries (at least one value is needed). A
frozen set might be represented with a {||} in the future. I stole the
syntax from F#. Numbers have a trailing letter indicating their types:
signed byte (y), short (s), long (l), float (f), fixed (m), arbitrary
precision (i), rational (r) and imaginary (j). Unsigned versions have
a u before the letter (uy).

Also, .. is the range operator in Unit. 0..10 means "0 through 10" and
0.1 means a floating point number (I missed a dot). 0

Re: suppressing bad characters in output PCDATA (converting JSON to XML)

[Stefan Behnel]

Adam Funk, 25.11.2011 14:50:

I'm converting JSON data to XML using the standard library's json and
xml.dom.minidom modules.  I get the input this way:

input_source = codecs.open(input_file, 'rb', encoding='UTF-8', errors='replace')


It doesn't make sense to use codecs.open() with a "b" mode.



big_json = json.load(input_source)


You shouldn't decode the input before passing it into json.load(), just 
open the file in binary mode. Serialised JSON is defined as being UTF-8 
encoded (or BOM-prefixed), not decoded Unicode.




input_source.close()


In case of a failure, the file will not be closed safely. All in all, use 
this instead:


with open(input_file, 'rb') as f:
big_json = json.load(f)



Then I recurse through the contents of big_json to build an instance
of xml.dom.minidom.Document (the recursion includes some code to
rewrite dict keys as valid element names if necessary)


If the name "big_json" is supposed to hint at a large set of data, you may 
want to use something other than minidom. Take a look at the 
xml.etree.cElementTree module instead, which is substantially more memory 
efficient.




and I save the document:

xml_file = codecs.open(output_fullpath, 'w', encoding='UTF-8', errors='replace')
doc.writexml(xml_file, encoding='UTF-8')
xml_file.close()


Same mistakes as above. Especially the double encoding is both unnecessary 
and likely to fail. This is also most likely the source of your problems.




I thought this would force all the output to be valid, but xmlstarlet
gives some errors like these on a few documents:

PCDATA invalid Char value 7
PCDATA invalid Char value 31


This strongly hints at a broken encoding, which can easily be triggered by 
your erroneous encode-and-encode cycles above.


Also, the kind of problem you present here makes it pretty clear that you 
are using Python 2.x. In Python 3, you'd get the appropriate exceptions 
when trying to write binary data to a Unicode file.


Stefan

--
http://mail.python.org/mailman/listinfo/python-list

Re: mailbox module difficulties

[Eduardo Alvarez]

On 2011-11-28, Peter Otten <__pete...@web.de> wrote:
> Eduardo Alvarez wrote:
>
>> however, if I do the following:
>> 
>> b = mailbox.Maildir("~/Maildir")
>> b.items()
>> 
>> I get an empty list.
>> 
>> I don't understand why this is so, specially since the last example in
>> the documentation shows a reference to a Maildir object being created.
>> Why does this happen?
>
> Could this be
>
> http://bugs.python.org/issue13254
>
> ?

Peter and Chris,

This is exactly it. I guess the version in my linux distribution is not
patched. I'll let the maintainer know, thank you!

Yours,

--
Eduardo Alvarez
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: correct usage of a generator?

[Mel Wilson]

Tim wrote:

> Hi, I need to generate a list of file names that increment, like 
this:
> fname1
> fname2
> fname3 and so on.
> 
> I don't know how many I'll need until runtime so I figure a 
generator is
> called for.
> 
> def fname_gen(stem):
> i = 0
> while True:
> i = i+1
> yield '%s%d' % (stem,i)
> 
> blarg = fname_gen('blarg')
> boo = fname_gen('boo')
> 
> n = 3
> for w in range(0,n):
> in_name = blarg.next()
> out_name = boo.next()
> 
> 
> This works, but is it the 'normal' way to accomplish the task when 
you
> don't know 'n' until run-time? thanks,

It's kind of overkill in the toy demo example, but if the main loop is 
a little more abstract, e.g.

for task in task_supplier():
in_name = blarg.next()
out_name = boo.next()
handle_task (task, in_name, out_name)

then it's obviously a good thing.

One quibble (that Peter Otten also suggested): if your business rules 
expect that files blarg25 and boo25 (for example) work together, then 
you'd be better off generating them together as a pair in a single 
generator call.  As it is, there's a chance of the blarg and boo 
generators getting out of step and supplying mismatched names.

Mel.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: mailbox module difficulties

[Peter Otten]

Eduardo Alvarez wrote:

> however, if I do the following:
> 
> b = mailbox.Maildir("~/Maildir")
> b.items()
> 
> I get an empty list.
> 
> I don't understand why this is so, specially since the last example in
> the documentation shows a reference to a Maildir object being created.
> Why does this happen?

Could this be

http://bugs.python.org/issue13254

?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: mailbox module difficulties

[Chris Angelico]

On Tue, Nov 29, 2011 at 4:21 AM, Eduardo Alvarez
 wrote:
> if I call a Maildir object directly, the module works perfectly. I can,
> for example, call
>
> mailbox.Maildir("~/Maildir").items()
>
> and get the expected list of (key,Message) pairs.
>
> however, if I do the following:
>
> b = mailbox.Maildir("~/Maildir")
> b.items()
>
> I get an empty list.

They ought to be equivalent. Can you post your whole code? Maybe
there's some other difference.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

mailbox module difficulties

[Eduardo Alvarez]

Hello, everyone,

I'm in the process of learning how to use the mailbox module with python
3.2. I've noticed the following seemingly inconsistent behavior:

if I call a Maildir object directly, the module works perfectly. I can,
for example, call

mailbox.Maildir("~/Maildir").items()

and get the expected list of (key,Message) pairs.

however, if I do the following:

b = mailbox.Maildir("~/Maildir")
b.items()

I get an empty list. 

I don't understand why this is so, specially since the last example in
the documentation shows a reference to a Maildir object being created.
Why does this happen?

yours,

--
Eduardo Alvarez
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: correct usage of a generator?

[Neil Cerutti]

On 2011-11-28, Steven D'Aprano
 wrote:
> On Mon, 28 Nov 2011 07:36:17 -0800, Tim wrote:
>> Hi, I need to generate a list of file names that increment, like this:
>> fname1
>> fname2
>> fname3 and so on.
>> 
>> I don't know how many I'll need until runtime so I figure a
>> generator is called for.
>> 
>> def fname_gen(stem):
>> i = 0
>> while True:
>> i = i+1
>> yield '%s%d' % (stem,i)
>> 
>> blarg = fname_gen('blarg')
>> boo = fname_gen('boo')

I don't see anything wrong with that. I've written similar code
in terms of itertools.count, myself. If I may make a suggestion,
it would be nice to zero-pad the number to achieve
lexicographical ordering of filenames. However, if you really
have no idea of the magnitude you might need that won't work. The
following assumes you'll need less than 1000.

counter = itertools.count()
...
with open("%03d" % counter.next(), "w") as the_next_file:
  ...

My Python < 3.0 is rusty, so sorry if I messed that up.

-- 
Neil Cerutti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: correct usage of a generator?

[Peter Otten]

Tim wrote:

> Hi, I need to generate a list of file names that increment, like this:
> fname1
> fname2
> fname3 and so on.
> 
> I don't know how many I'll need until runtime so I figure a generator is
> called for.
> 
> def fname_gen(stem):
> i = 0
> while True:
> i = i+1
> yield '%s%d' % (stem,i)
> 
> blarg = fname_gen('blarg')
> boo = fname_gen('boo')
> 
> n = 3
> for w in range(0,n):
> in_name = blarg.next()
> out_name = boo.next()
> 
> 
> This works, but is it the 'normal' way to accomplish the task when you
> don't know 'n' until run-time? thanks,

As a fan of the itertools module I would spell it (untested)

from itertools import count, islice, izip

def fname_gen(stem):
return ("%s%d" % (stem, i) for i in count(1))
# ...
for in_name, out_name in islice(izip(blarg, boo), n):
   #...

but your way is perfectly OK.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: correct usage of a generator?

[Steven D'Aprano]

On Mon, 28 Nov 2011 07:36:17 -0800, Tim wrote:

> Hi, I need to generate a list of file names that increment, like this:
> fname1
> fname2
> fname3 and so on.
> 
> I don't know how many I'll need until runtime so I figure a generator is
> called for.
> 
> def fname_gen(stem):
> i = 0
> while True:
> i = i+1
> yield '%s%d' % (stem,i)
> 
> blarg = fname_gen('blarg')
> boo = fname_gen('boo')
> 
> n = 3
> for w in range(0,n):
> in_name = blarg.next()
> out_name = boo.next()
> 
> 
> This works, but is it the 'normal' way to accomplish the task when you
> don't know 'n' until run-time? thanks,

Looks perfectly fine to me. In Python 2.6 onwards, I'd write next(blarg) 
rather than blarg.next(), and similarly for boo. In Python 3.x, you have 
to use next(blarg).

If I were to nit-pick, I'd write the last part as:

for _ in range(3):
in_name = blarg.next()
out_name = boo.next()

where _ is the traditional "don't care" name in Python.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Proper way to delete/kill a logger?

[cassiope]

Thanks Chris and JM, I will explore how much work it's going to take
to change the various scripts to _always_ starting the logger from
main().
As further explanation - this code predates the logging module, and
many of the functions/classes had an optional argument for the home-
made
logger - and where the caller didn't provide it, it was locally
created.
The unit tests were carefully enough put together to provide almost
complete coverage, resulting in creating the logger possibly a dozen
or more times in the course of the tests.

So I appreciate what "doing it the right way" means, I was just hoping
not to have to go there, as I have a lot of code that uses the old
structures.  It makes it harder to justify moving to the "newer"
module.

I'll have to try the logger.handlers=[] approach, thanks.
-- 
http://mail.python.org/mailman/listinfo/python-list

correct usage of a generator?

[Tim]

Hi, I need to generate a list of file names that increment, like this:
fname1
fname2
fname3 and so on.

I don't know how many I'll need until runtime so I figure a generator is called 
for.

def fname_gen(stem):
i = 0
while True:
i = i+1
yield '%s%d' % (stem,i)

blarg = fname_gen('blarg')
boo = fname_gen('boo')

n = 3
for w in range(0,n):
in_name = blarg.next()
out_name = boo.next()


This works, but is it the 'normal' way to accomplish the task when you don't 
know 'n' until run-time?
thanks,
--Tim
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Proper way to delete/kill a logger?

[Roy Smith]

In article ,
 Jean-Michel Pichavant  wrote:

> Loggers are static objects managed by the module itself.

For reasons I can't quite explain, that sentence makes me want to sing 
The Lumberjack Song.  "I'm a logger(*) and I'm OK..."

(*) Yes, I know that's not right.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: sick of distribute, setup, and all the rest...

[Andreas Perstinger]

On 2011-11-28 14:14, rusi wrote:

On Nov 28, 4:42 pm, Steven D'Aprano  wrote:

 We don't chase people down on the street and lecture them about the
 problems we think they are having, we answer questions about ACTUAL
 problems that they have experienced and asking about.



 ... ever question gets an answer, and we're discussing
 things about as much as we ought to.


How about applying these claims to the OP?



OP asked only one question (the rest was just ranting) and Steven 
answered it (IMHO in the right manner).


OP never mentioned specific problems or what's wrong with any of the 
distribution systems. So what answers are you expecting from such a post?


Bye, Andreas


--
http://mail.python.org/mailman/listinfo/python-list

Re: sick of distribute, setup, and all the rest...

[Steven D'Aprano]

On Mon, 28 Nov 2011 05:14:27 -0800, rusi wrote:

> On Nov 28, 4:42 pm, Steven D'Aprano  +comp.lang.pyt...@pearwood.info> wrote:
>> We don't chase people down on the street and lecture them about the
>> problems we think they are having, we answer questions about ACTUAL
>> problems that they have experienced and asking about.
> 
>> ... ever question gets an answer, and we're discussing things about as
>> much as we ought to.
> 
> How about applying these claims to the OP?

The OP ranted that the existing packaging systems are an "all-out 
disgrace" (his words), without giving even a single example of a concrete 
problem, and unilaterally declared that this needs the personal attention 
of Guido van Rossum. There's a word for posts like that one: starts with 
T, ends in ROLL.

Presumably the OP believes that not only should he not have to solve his 
own problems with existing packaging systems, but he should not have to 
even describe those supposed problems.

The OP's only question was "when is python going to get a decent module 
distribution system???", to which the right answer is presumably "about a 
decade ago".

Decent does not necessarily mean perfect. If the OP decides to ask a 
sensible question about an actual problem, I'm sure he'll get a sensible 
answer. Perhaps not the answer he is hoping for, but an an answer.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Proper way to delete/kill a logger?

[Jean-Michel Pichavant]

cassiope wrote:

I've been trying to migrate some code to using the standard python
logging classes/objects.  And they seem quite capable of doing what I
need them to do.  Unfortunately there's a problem in my unit tests.
It's fairly common to have to create quite a few entities in the
course of a series of tests.  What appears to be happening is that the
loggers don't get entirely eliminated, so that new invocations end up
spewing output messages from each of the loggers that were started
with this invocation of the python interpreter.

I haven't found a function within the logging module that completely
kills a given instance.  The removeHandler() function seems to leave a
stdout/stderr output even if all the assigned handlers have been
removed.  I've tried a few workarounds, such as increasing the level
to an absurdly large level, which mostly kinda works, and killing the
old entity before creating the new test version.

There is probably something simple that I'm missing.  If you know what
that is, please point me to that fine manual - I'd appreciate it.
Thanks!

-f
  
Loggers are static objects managed by the module itself. When you create 
one, it won't be removed until you leave the shell. Thas is way it is 
advise not to create thousands of loggers with different names.

That's the module design, nothing you can do about it.

It takes a little time to get used to it but the logging documentation 
has a lot of examples showing how to use to module.
Your main problem is that some of your test instances are configuring 
the loggers, they should not. Configuration should be done in the 'main' 
function *only*.


import logging, sys

class Test1:
   def __init__(self):
   self.logger = logging.getLogger(self.__class__.__name__) # 
create a new logger or reuse one if a logger with that name already exists

   self.logger.info('I am created')
   # adding a handler to the logger here would be a mistake, 
configuration is let to the user, in this case the program main entry point
   # objects raising log events should not care about how they are 
formated/displayed

class Test2:
   def __init__(self):
   self.logger = logging.getLogger(self.__class__.__name__)
   self.logger.info('I am created')

def main():
   # configure here the logger, usually the root logger
   root = logging.getLogger()
   root.handlers = [] # required if you don't want to exit the shell 
between 2 executions (not very wise)

   root.setLevel(logging.DEBUG)
   root.addHandler(logging.StreamHandler(sys.stdout))
   root.handlers[-1].setFormatter(logging.Formatter('%(name)s - 
%(levelname)s - %(message)s'))


   t1 = Test1()
   t2 = Test2()
   t3 = Test2()

if __name__ == '__main__':
   main()

> run test.py
Test1 - INFO - I am created
Test2 - INFO - I am created
Test2 - INFO - I am created


JM

PS : one way to cleanup a logger is to remove all its handlers, i.e. 
logger.handlers = [], but if you need to do this you may have done 
something wrong.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Cursor.fetchall

[Jean-Michel Pichavant]

Jayron Soares wrote:

Hi Felipe,

I did, however I got this error:

Traceback (most recent call last):
  File "/home/jayron/Downloads/grafos.py", line 48, in 
g, e = ministro_lei()
  File "/home/jayron/Downloads/grafos.py", line 34, in ministro_lei
for i in G.degree():
TypeError: 'int' object is not iterable

I could not understood what's going on, I've tried so many different 
approaches to solve this problem, but unfortunately no success.


Cheers


 
2011/11/28 Felipe Vinturini >


Hi Jayron,

Instead of using "Q" to loop over the result, use: "dbcursor".

resp = dbcursor.fetchall()

I hope it helps.

Regards,
Felipe.

On Mon, Nov 28, 2011 at 9:54 AM, Jayron Soares
mailto:jayronsoa...@gmail.com>> wrote:

Hi guys!

I'm stuck at a problem, when I run the follow code:

http://pastebin.com/4Gd9V325

I get this error:

Traceback (most recent call last):
  File "/home/jayron/Downloads/grafos.py", line 49, in 
g, e = ministro_lei()
  File "/home/jayron/Downloads/grafos.py", line 24, in
ministro_lei
resp = Q.fetchall()
AttributeError: 'long' object has no attribute 'fetchall'

Please any help ?

cheers



Hello,

You are iterating on G.degree(), which is fine when it is a dictionary. 
However regarding DiGraph documentation:
"Returns :   
nd : dictionary, or number
A dictionary with nodes as keys and degree as values or a number if a 
single node is specified."


So you may get an integer and thus cannot iterate on it.

You could use
if type(G.degree()) is int:
   lista.append(G.degree())
else:
   for i in G.degree().values():
  lista.append(i)

I'm quite surprised that a distributed graph API uses such inconsistent 
interface. I guess you'll have to live with it.


JM


PS : Try to code & document in English, it's much better especially when 
asking for help on this list, mixing spanish and english has few 
benefits since you may bother both spanish and english ppl :o)

--
http://mail.python.org/mailman/listinfo/python-list

Re: sick of distribute, setup, and all the rest...

[rusi]

On Nov 28, 4:42 pm, Steven D'Aprano  wrote:
> We don't chase people down on the street and lecture them about the
> problems we think they are having, we answer questions about ACTUAL
> problems that they have experienced and asking about.

> ... ever question gets an answer, and we're discussing
> things about as much as we ought to.

How about applying these claims to the OP?


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Pragmatics of the standard is() function

[Jean-Michel Pichavant]

candide wrote:
In which cases should we use the is() function ? The is() function 
compares identity of objects rather than values so I was wondering in 
which circumstances comparing identities of objects is really vital.


Examining well reputated Python source code, I realize that is() 
function is mainly used in the following set form :


spam is None

But how much "spam is None" is different from "spam == None" ?



is() function makes comparaison of (abstract representation of) 
adresses of objects in memory. Comparing addresses of objects is a low 
level feature performed by low level langages such as C but seldom 
needed in high level languages like Python, isn'it ?
I remember meeting a use case where testing identity is required, when 
you are searching for an instance containing a specific object:


class Someone:
   def __init__(self, name, car):
   self.name = name
   self.car = car

class Car:
   def __init__(self, brand):
   self.brand = brand
   def __eq__(self, other):
   return self.brand == other.brand

people = { 'bob':Someone('bob', Car('chrys')), 'cindy': Someone('cindy', 
Car('Volk')), 'carlos':Someone('carlos', Car('Volk'))}

aCar = people['carlos'].car
print "people owning a Volk car", [ people[ppl].name for ppl in people 
if people[ppl].car == Car('Volk')]
print "people owning Carlos's car", [ people[ppl].name for ppl in people 
if people[ppl].car is aCar]


people owning a Volk car ['carlos', 'cindy']
people owning Carlos's car ['carlos']

JM
--
http://mail.python.org/mailman/listinfo/python-list

Re: Cursor.fetchall

[Jayron Soares]

Hi Felipe,

I did, however I got this error:

Traceback (most recent call last):
  File "/home/jayron/Downloads/grafos.py", line 48, in 
g, e = ministro_lei()
  File "/home/jayron/Downloads/grafos.py", line 34, in ministro_lei
for i in G.degree():
TypeError: 'int' object is not iterable

I could not understood what's going on, I've tried so many different
approaches to solve this problem, but unfortunately no success.

Cheers



2011/11/28 Felipe Vinturini 

> Hi Jayron,
>
> Instead of using "Q" to loop over the result, use: "dbcursor".
>
> resp = dbcursor.fetchall()
>
> I hope it helps.
>
> Regards,
> Felipe.
>
> On Mon, Nov 28, 2011 at 9:54 AM, Jayron Soares wrote:
>
>> Hi guys!
>>
>> I'm stuck at a problem, when I run the follow code:
>>
>> http://pastebin.com/4Gd9V325
>>
>> I get this error:
>>
>> Traceback (most recent call last):
>>   File "/home/jayron/Downloads/grafos.py", line 49, in 
>> g, e = ministro_lei()
>>   File "/home/jayron/Downloads/grafos.py", line 24, in ministro_lei
>> resp = Q.fetchall()
>> AttributeError: 'long' object has no attribute 'fetchall'
>>
>> Please any help ?
>>
>> cheers
>>
>>
>> --
>> *" A Vida é arte do Saber...Quem quiser saber tem que Estudar!"*
>>
>> http://bucolick.tumblr.com
>> http://artecultural.wordpress.com/
>>
>>
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>>
>


-- 
*" A Vida é arte do Saber...Quem quiser saber tem que Estudar!"*

http://bucolick.tumblr.com
http://artecultural.wordpress.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: cmd.Cmd asking questions?

[Robert Kern]

On 11/28/11 12:12 PM, Tim Chase wrote:

Are there best-practices for creating wizards or asking various questions
(whether yes/no or text/numeric entry) in a cmd.Cmd class? Something like the
imaginary confirm() and get_string() methods here:

class MyCmd(cmd.Cmd):
def do_name(self,line):
s = get_string(prompt=line, default="Whatever")
...
def do_save(self,line):
if os.path.isfile(line):
if not confirm("%r exists. Continue?", True): return
self.save(line)
def save(self, filename):
...

I can monkey with printing messages and using raw_input(), but I'd like to know
if there's a better way (such as something interacting with readline for
text-entry-with-history-and-completion,


If you import readline, then any following uses of raw_input() will 
automatically use readline. You may want to swap out the history when you use 
get_string() or confirm() so they don't mess up the regular Cmd history, but the 
basic functionality should work out-of-box.



or raw-character input for Y/N answers
rather than the need to hit , making it feel more uniform),


I actually have a preference for needing to press enter for Y/N answers, too. 
It's distinctly *less* uniform to have some questions requiring an enter and 
some not. It can be unpleasantly surprising to the user, too.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

--
http://mail.python.org/mailman/listinfo/python-list

Re: suppressing bad characters in output PCDATA (converting JSON to XML)

[Steven D'Aprano]

On Fri, 25 Nov 2011 13:50:01 +, Adam Funk wrote:

> I'm converting JSON data to XML using the standard library's json and
> xml.dom.minidom modules.  I get the input this way:
> 
> input_source = codecs.open(input_file, 'rb', encoding='UTF-8',
> errors='replace') big_json = json.load(input_source)
> input_source.close()
> 
> Then I recurse through the contents of big_json to build an instance of
> xml.dom.minidom.Document (the recursion includes some code to rewrite
> dict keys as valid element names if necessary), 

How are you doing that? What do you consider valid?


> and I save the document:
> 
> xml_file = codecs.open(output_fullpath, 'w', encoding='UTF-8',
> errors='replace') doc.writexml(xml_file, encoding='UTF-8')
> xml_file.close()
> 
> 
> I thought this would force all the output to be valid, but xmlstarlet
> gives some errors like these on a few documents:

It will force the output to be valid UTF-8 encoded to bytes, not 
necessarily valid XML.


> PCDATA invalid Char value 7
> PCDATA invalid Char value 31

What's xmlstarlet, and at what point does it give this error? It doesn't 
appear to be in the standard library.



> I guess I need to process each piece of PCDATA to clean out the control
> characters before creating the text node:
> 
>   text = doc.createTextNode(j)
>   root.appendChild(text)
> 
> What's the best way to do that, bearing in mind that there can be
> multibyte characters in the strings?

Are you mixing unicode and byte strings?

Are you sure that the input source is actually UTF-8? If not, then all 
bets are off: even if the decoding step works, and returns a string, it 
may contain the wrong characters. This might explain why you are getting 
unexpected control characters in the output: they've come from a badly 
decoded input.

Another possibility is that your data actually does contain control 
characters where there shouldn't be any.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

cmd.Cmd asking questions?

[Tim Chase]

Are there best-practices for creating wizards or asking various 
questions (whether yes/no or text/numeric entry) in a cmd.Cmd 
class?  Something like the imaginary confirm() and get_string() 
methods here:


  class MyCmd(cmd.Cmd):
def do_name(self,line):
  s = get_string(prompt=line, default="Whatever")
  ...
def do_save(self,line):
  if os.path.isfile(line):
if not confirm("%r exists. Continue?", True): return
  self.save(line)
def save(self, filename):
  ...

I can monkey with printing messages and using raw_input(), but 
I'd like to know if there's a better way (such as something 
interacting with readline for 
text-entry-with-history-and-completion, or raw-character input 
for Y/N answers rather than the need to hit , making it 
feel more uniform),


Thanks,

-tkc


--
http://mail.python.org/mailman/listinfo/python-list

Re: Cursor.fetchall

[Felipe Vinturini]

Hi Jayron,

Instead of using "Q" to loop over the result, use: "dbcursor".

resp = dbcursor.fetchall()

I hope it helps.

Regards,
Felipe.

On Mon, Nov 28, 2011 at 9:54 AM, Jayron Soares wrote:

> Hi guys!
>
> I'm stuck at a problem, when I run the follow code:
>
> http://pastebin.com/4Gd9V325
>
> I get this error:
>
> Traceback (most recent call last):
>   File "/home/jayron/Downloads/grafos.py", line 49, in 
> g, e = ministro_lei()
>   File "/home/jayron/Downloads/grafos.py", line 24, in ministro_lei
> resp = Q.fetchall()
> AttributeError: 'long' object has no attribute 'fetchall'
>
> Please any help ?
>
> cheers
>
>
> --
> *" A Vida é arte do Saber...Quem quiser saber tem que Estudar!"*
>
> http://bucolick.tumblr.com
> http://artecultural.wordpress.com/
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Cursor.fetchall

[Jayron Soares]

Hi guys!

I'm stuck at a problem, when I run the follow code:

http://pastebin.com/4Gd9V325

I get this error:

Traceback (most recent call last):
  File "/home/jayron/Downloads/grafos.py", line 49, in 
g, e = ministro_lei()
  File "/home/jayron/Downloads/grafos.py", line 24, in ministro_lei
resp = Q.fetchall()
AttributeError: 'long' object has no attribute 'fetchall'

Please any help ?

cheers


-- 
*" A Vida é arte do Saber...Quem quiser saber tem que Estudar!"*

http://bucolick.tumblr.com
http://artecultural.wordpress.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

python 2.5 and ast

[Andrea Crotti]

I'm happily using the ast module to analyze some code,
but my scripts need also to run unfortunately on python 2.5

The _ast was there already, but the ast helpers not yet.
Is it ok if I just copy over the source from the ast helpers in my code base
or is there a smarter way?
(I don't even need all of them, just "parse" and NodeVisitor at the moment)
--
http://mail.python.org/mailman/listinfo/python-list

Re: sick of distribute, setup, and all the rest...

[Steven D'Aprano]

On Sun, 27 Nov 2011 23:18:15 -0800, rusi wrote:

> On Nov 28, 9:37 am, alex23  wrote:
> 
>> With that approach in mind, I've never had any real issues using pip,
>> virtualenv etc for managing my development environment.
> 
> Yes that is in a way my point also: we discuss (things like) pip,
> virtualenv etc too little.

I don't know about that. I think we discuss things like pip, etc. exactly 
the right amount.


> Try working out the ratio of the number of helps/tutorials on
> functions/lists/types/classes to those on these extra-linguistic
> features needed for environment/build/deployment/versioning and you can
> see the skewness of focus

We don't chase people down on the street and lecture them about the 
problems we think they are having, we answer questions about ACTUAL 
problems that they have experienced and asking about. If there are 10 or 
100 times more answers about (say) classes than about (say) pip, that is 
because there are 10 or 100 times as many questions about classes.

Maybe that's because pip users are cleverer, more experienced and don't 
have problems; maybe it's because only 1 in 100 people go on to use pip. 
Maybe it's because pip is a heap of trash that nobody touches; or perhaps 
it is so fantastic that nobody has any problems with it. Whatever the 
reason, there's no great big queue of unanswered questions about pip that 
I can see. Hence, ever question gets an answer, and we're discussing 
things about as much as we ought to.

(I don't mean to single out pip, it is just an example.)


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: lxml precaching DTD for document verification.

[Gelonida N]

Thanks Stefan,


On 11/28/2011 08:38 AM, Stefan Behnel wrote:
> Gelonida N, 27.11.2011 18:57:
>> I'd like to verify some (x)html / / html5 / xml documents from a server.
>>
>> These documents have a very limited number of different doc types / DTDs.
>>
>> So what I would like to do is to build a small DTD cache and some code,
>> that would avoid searching the DTDs over and over from the net.
>>
>> What would be the best way to do this?
> 
> Configure your XML catalogues.
. . .
> 
> Yes, catalogue lookups generally happen through the public ID.
> 
> . . . 
> Does this help?
> 
> http://lxml.de/resolvers.html#xml-catalogs
> 
> http://xmlsoft.org/catalog.html

These links look perfect.
> 
> They should normally come pre-configured on Linux distributions, but you
> may have to install additional packages with the respective DTDs. Look
> for any packages with "dtd" and "html" in their name, for example.
> 
Thanks once more.
Indeed the package w3c-dtd-xhtml wasn't installed on my Ubuntu host.

I'll check this lateron today.
(Just have to remove my own hackish cashing solution, which downloads if
not found in a cash dir)



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: my new project, is this the right way?

[88888 Dihedral]

On Sunday, November 27, 2011 4:49:14 PM UTC+8, 8 Dihedral wrote:
> On Sunday, November 27, 2011 4:29:52 PM UTC+8, 8 Dihedral wrote:
> > On Sunday, November 27, 2011 12:03:26 PM UTC+8, Matt Joiner wrote:
> > > Sounds like you want a key-value store. If it's a lot of data, you may
> > > still want a "database", I think it's just relational databases that
> > > you're trying to avoid?
> > > 
> > > On Sun, Nov 27, 2011 at 10:41 AM, 8 Dihedral
> > >  wrote:
> > > > On Saturday, November 26, 2011 1:01:34 AM UTC+8, rusi wrote:
> > > >> On Nov 14, 3:41 pm, Tracubik  wrote:
> > > >> > Hi all,
> > > >> > i'm developing a new program.
> > > >> > Mission: learn a bit of database management
> > > >> > Idea: create a simple, 1 window program that show me a db of movies 
> > > >> > i've
> > > >> > seen with few (<10) fields (actors, name, year etc)
> > > >> > technologies i'll use: python + gtk
> > > >> > db: that's the question
> > > >> >
> > > >> > since i'm mostly a new-bye for as regard databases, my idea is to use
> > > >> > sqlite at the beginning.
> > > >> >
> > > >> > Is that ok? any other db to start with? (pls don't say mysql or 
> > > >> > similar,
> > > >> > they are too complex and i'll use this in a second step)
> > > >> >
> > > >> > is there any general tutorial of how to start developing a database? 
> > > >> > i
> > > >> > mean a general guide to databases you can suggest to me?
> > > >> > Thank you all
> > > >> >
> > > >> > MedeoTL
> > > >> >
> > > >> > P.s. since i have a ods sheet files (libreoffice calc), is there a 
> > > >> > way to
> > > >> > easily convert it in a sqlite db? (maybe via csv)
> > > >>
> > > >> To learn DBMS you need to learn sql
> > > >> [Note sql is necessary but not sufficient for learning DBMS]
> > > >> I recommend lightweight approaches to start with -- others have
> > > >> mentioned access, libreoffice-base.
> > > >> One more lightweight playpen is firefox plugin sqlite-manager
> > > >>
> > > >> > Is that ok? any other db to start with? (pls don't say mysql or 
> > > >> > similar,
> > > >> > they are too complex and i'll use this in a second step)
> > > >>
> > > >> Correct. First you must figure out how to structure data -- jargon is
> > > >> normalization.
> > > >> After that you can look at transactions, ACID, distribution and all
> > > >> the other good stuff.
> > > >
> > > > If I have a fast hash library  that each hash function supports 
> > > > insertion and deletion and can be frozen to be stored into the file 
> > > > system if desired and retrieved lator . Can I use several hashes to 
> > > > replace a database that is slow and expensive?
> > > >
> > > > --
> > > > http://mail.python.org/mailman/listinfo/python-list
> > > >
> > 
> > A database with most entries in fixed bytes and types and several  types 
> > that can have varied lengths of 8 to 256 bytes. If an entry is larger than 
> > 256 bytes, it will be saved as a file but only the file name is saved in my 
> > data base.
> >   
> > Each entry is just a type and value stored  in a row of my database.
> > I''ll limit the number of entries in a row or so called a recored to some 
> > limit first, 1024 first. 
> >
> > Can I do this in 1024 hashes in python ?
> Sorry I 'll use (k=column_in_a_row, v=value) and (k=value, v=column_in_a_row)
> Thus, two hashes per column in  my database, therefore  2048 hashes to manage 
> the data base.

For the same value stored , I need a column_no+next stored, a list.   
 All relations can be derived.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Proper way to delete/kill a logger?

[Chris Withers]

On 28/11/2011 04:16, cassiope wrote:

I've been trying to migrate some code to using the standard python
logging classes/objects.  And they seem quite capable of doing what I
need them to do.  Unfortunately there's a problem in my unit tests.
It's fairly common to have to create quite a few entities in the
course of a series of tests.  What appears to be happening is that the
loggers don't get entirely eliminated, so that new invocations end up
spewing output messages from each of the loggers that were started
with this invocation of the python interpreter.


Two suggestions:

- unless you are specifically testing the logging set up of your 
application, your code under test shouldn't be setting up logging.


- if you want to check that your code under test is emitting log 
messages correctly, use a LogCapture from testfixtures:


http://packages.python.org/testfixtures.

cheers,

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
--
http://mail.python.org/mailman/listinfo/python-list