Re: Log rolling question

[NickC]

If you're on Python 2.4, then consider whether or not you can use a
TimedRotatingLogFileHandler from the logging module to handle this for
you:
http://www.python.org/doc/2.4.1/lib/node344.html

Of course, that only works if defining a "month" as 30 days is
acceptable. If you genuinely need calendar months, then you still need
to do it manually.

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

Re: case/switch statement?

[NickC]

Andrew Durdin wrote:
> In this case the dictionary is obviously a better and clearer choice.
> I've generally found for other circumstances where I've used switch
> statements that the code ends up more readable if it's reorganised so
> that the switch statements are all of the form above, or are
> eliminated entirely--so I don't miss a switch/case statement in
> Python.

I find the lack of a switch statement encourages me to write
data-driven programs (which is a god-send when I have to enhance them
later to deal with additional cases).

The thing I love most about Python is the fact that callables can be
slung around at run-time, just like any other object. So, I set up
(usually for command-line options) mappings from options to callables
which define "how to perform action x".

Then as the options are translated, I query the lookup tables, and
store the results in appropriately named variables (e.g
"create_connection", "connect_link" for a program I use to test serial
data circuits with a variety of connections and links running over
different hardware).

The main body of the program is then comparatively trivial, because it
just calls methods whose names describe (in a high-level way) what they
do. A new connection or link type can be handled just by adding an
entry to the appropriate dictionary.

Basically, it's the GoF Strategy pattern, without all the pain that's
required to set it up in static languages.

Cheers,
Nick.

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

Re: Which kid's beginners programming - Python or Forth?

[NickC]

> Gentle folk of comp.lang.python, I heartily thank you all for your
> input.  I think I'm taking the boys through the door marked "Logo."  We
> may be back this way, though.  We will likely need MORE in the nebulous
> future.  I am impressed with the outpouring of support here!

Before you commit totally to the LOGO idea, take a look at Guido van
Robot:
http://gvr.sourceforge.net/
http://gvr.sourceforge.net/about.php
http://gvr.sourceforge.net/lessons/rfrank/

Cheers,
Nick.

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

Re: Favorite non-python language trick?

[NickC]

Steven D'Aprano wrote:
> with colour do begin
> red := 0; blue := 255; green := 0;
> end;
>
> instead of:
>
> colour.red := 0; colour.blue := 255; colour.green := 0;

c = colour
c.red = 0; c.blue = 255; c.green = 0
del c # Not strictly needed, but limits the scope of c

When everything's a reference, the Pascal 'with' syntax doesn't gain
you anything over a single-letter variable name. As I recall, it's
handy in Pascal because record assignment has value semantics rather
than reference semantics.

Cheers,
Nick.

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

Re: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code

[NickC]

Ralf,

I'd be very interested to hear your opinion on the 'namespace' module,
which looks at addressing some of these issues (the Record object, in
particular).  The URL is http://namespace.python-hosting.com, and any
comments should be directed to the [EMAIL PROTECTED]
discussion list.

Regards,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.blogspot.com

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

Re: Path inherits from basestring again

[NickC]

[Re: alternatives to overloading '/']

Is there a reason the Path constructor is limited to a single argument?
If it allowed multiple arguments, the following would seem very
straightforward:

p = Path(somePath, user.getFolder(), 'archive', oldPath + ".bak")

I'm usually not much of a purist, but C++ has convinced me that
overloading an operator to mean something entirely unrelated to its
mathematical meaning can be very unwise.

Regards,
Nick C.

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

Re: Path inherits from basestring again

[NickC]

[Re: how to get at the base class]

Do you really want to have a "only works for Path" way to get at the
base class, rather than using the canonical Path.__bases__[0]?

How about a new property in the os.path module instead? Something like
os.path.path_type.

Then os.path.path_type is unicode if and only if
os.path.supports_unicode_filenames is True. Otherwise,
os.path.path_type is str.

Then converting a Path to str or unicode is possible using:

as_str_or_unicode = os.path.path_type(some_path)

The other thing is that you can simply make Path inherit from
os.path.path_type.

Regards,
Nick C.

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

Re: Python 2.4 online certification - new items available for Beta testing

[NickC]

[EMAIL PROTECTED] wrote:
> Randy> There is a free Beta test of a Python 2.4 Certification test
> Randy> available at Brainbench.com. They are a provider of skills-based
> Randy> certification exams.  Go to the link below to find the test. It
> Randy> is free to take the test.
>
> Randy> http://www.brainbench.com/xml/bb/common/testcenter/betatests.xml
>
> I've given up on Brainbench.  Ignoring the possibility that their
> certification tests may not be all that useful, they never stopped spamming
> me, so I refuse to help them with anything.
>
> Skip

I went through their first test module (although using a mailinator
address after this testimonial from Skip) and I think "Beta" is
generous. Try "pre-alpha" - i marked nearly half (maybe more than half)
of the 20 questions as "no correct answer", and a number of the others
included sample code that stank to high heaven.

I also pointed out that "what does this code do?" type questions are
pretty pointless for a language that comes with an interactive
interpreter (I would actually be somewhat disappointed with any Python
programmer whose automatic reaction to such a question involving
deliberately obfuscated code *wasn't* to try it out on the nearest
interpreter prompt).

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

Re: Are Python's reserved words reserved in places they dont need to be?

[NickC]

Fredrik Lundh wrote:
> Antoon Pardon wrote:
>
> > One place where I would use such a feature is in a unittest
> > package.  I think being able to write self.assert or self.raise
> > looks better than having to append an underscore.
>
> patch here:
>
> http://mail.python.org/pipermail/python-list/2001-June/047996.html
>
> 

Heh. Imagine how much more fun the introduction of conditional
expressions and the yield statement -> yield expression transition in
Python 2.5 would have been if Python 2.4 had used this behaviour :)

Cheers,
Nick.

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

Re: Would Anonymous Functions Help in Learning Programming/Python?

[NickC]

On Sep 24, 9:16 pm, Bruno Desthuilliers  wrote:
> Matthew Woodcraft a écrit :
> > One reason for the different syntax is that functions, unlike most
> > other objects, know their own names (which can be shown in tracebacks
> > and the like).
>
> Nope. They know *one* of their names - the one they've been given when
> first instanciated. Which may or not be the name used to get at them...

That's exactly the point - a function may be given many names through
the assignment statement, just like any other data value. However, the
*first* name given to a function (the one in the def statement) is
special, as that is the name the function knows *itself* by.

While a function *can* be treated like any other piece of data once
you have a reference to one, the original statement does a lot more
than a normal assignment does:
  - being within the scope of a function significantly alters name
binding and lookup
  - return statements and yield statements are meaningful only within
the scope of a function
  - you can attach decorators to a function definition
  - you can include a docstring in a function definition

For the original poster, I suggest trying some of the other
suggestions in this thread, where you skip the def statement and
instead look at manipulating standard library functions like math.sin
and math.cos. Using a dictionary to select a function to run may be a
good trick to illustrate the usefulness of this technique (e.g.
passing in a command line argument to choose a function to call to
generate a test sequence)

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

Re: Python 3.0 migration plans?

[NickC]

On Sep 30, 2:29 am, John Roth <[EMAIL PROTECTED]> wrote:
> I was thinking of starting work on converting Python FIT to 3.0, and
> then they posted PEP 3137. I think it's a real good idea, but it shows
> that 3.0a1 isn't ready for a conversion effort.
>
> http://www.python.org/dev/peps/pep-3137/
>
> I'll look at it again in a year or so.
>
> John Roth

When 3.0b1 comes out is probably the time to start looking seriously
at conversion. Until then, major course corrections (like PEP 3137)
will still be a possibility. Before the first beta, the best idea is
probably just to keep a watchful eye on the development to see if you
spot any show-stopper problems that might lead to the need for such a
course correction :)

Regards,
Nick.

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

Re: getting n items at a time from a generator

[NickC]

On Dec 27 2007, 11:31 pm, Kugutsumen <[EMAIL PROTECTED]> wrote:
> On Dec 27, 7:24 pm, Terry Jones <[EMAIL PROTECTED]> wrote:
>
>
>
> > > "Kugutsumen" == Kugutsumen  <[EMAIL PROTECTED]> writes:
>
> > Kugutsumen> On Dec 27, 7:07 pm, Paul Hankin <[EMAIL PROTECTED]> wrote:
>
> > >> On Dec 27, 11:34 am, Kugutsumen <[EMAIL PROTECTED]> wrote:
>
> > >> > I am relatively new the python language and I am afraid to be missing
> > >> > some clever construct or built-in way equivalent to my 'chunk'
> > >> > generator below.
>
> > Kugutsumen> Thanks, I am going to take a look at itertools.  I prefer the
> > Kugutsumen> list version since I need to buffer that chunk in memory at
> > Kugutsumen> this point.
>
> > Also consider this solution from O'Reilly's Python Cookbook (2nd Ed.) p705
>
> > def chop(iterable, length=2):
> > return izip(*(iter(iterable),) * length)
>
> > Terry
> > [snip code]
>
> > Try this instead:
>
> > import itertools
>
> > def chunk(iterator, size):
> > # I prefer the argument order to be the reverse of yours.
> > while True:
> > chunk = list(itertools.islice(iterator, size))
> > if chunk: yield chunk
> > else: break
>
> Steven, I really like your version since I've managed to understand it
> in one pass.
> Paul's version works but is too obscure to read for me :)
>
> Thanks a lot again.

To work with an arbitrary iterable, it needs an extra line at the
start to ensure the iterator items are consumed correctly each time
around the loop. It may also be better to ensure the final item is the
same length as the other items - if that isn't the case (you want to
know where the data really ends) then leave out the parts relating to
adding the padding object.

import itertools

def chunk(iterable, size, pad=None):
iterator = iter(iterable)
padding = [pad]
while True:
chunk = list(itertools.islice(iterator, size))
if chunk:
yield chunk + (padding*(size-len(chunk)))
else:
break

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

Re: Bizarre behavior with mutable default arguments

[NickC]

On Jan 1, 3:22 am, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
> On Dec 31, 10:58 am, Odalrick <[EMAIL PROTECTED]> wrote:
>
> > I'm surprised noone has said anything about the why of default
> > mutables. I think it is becasue it isn't easy to do it an other way.
>
> [...]
>
> There is an easy enough way: evaluate default values when the function
> is called rather than when it is defined.  This behaviour comes with
> its own caveats as well I imagine, and it's not 'as easy' to implement
> as the current one.

As Odalrick notes, there is no way to give different calls to a
function their own copies of mutable default arguments without re-
evaluating the defaults every time the function is called. The
horrendous performance implications mean that that simply isn't going
to happen. So the status quo, where the defaults are calculated once
when the function is defined and the result cached in the function
object is unlikely to change.

> What's good about the current behaviour is that it is easy to reason
> with (once you know what happens), even though you almost have to get
> bitten once.  But using this to have static variable is extremely ugly
> IMHO.

The only thing it doesn't give you is a static variable that isn't
visible to the caller. Py3k's keyword-only arguments (PEP 3102) will
make those cases a little tidier, since it won't be possible to
accidentally replace the static variables by providing too many
positional arguments.

I believe the suggestion of permitting static variables after the **
entry in a function's parameter list was raised during the PEP 3102
discussions, but never gained much traction over a '_cache={}' keyword-
only argument approach (and the latter has the distinct advantage of
being *much* easier to test, since you can override the cache from the
test code to ensure it is being handled correctly).

Cheers,
Nick.

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

Re: Module/package hierarchy and its separation from file structure

[NickC]

On Jan 31, 12:27 am, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
> Python stores filename and line number information in code objects
> (only). If you have a reference to any code object (a method, a
> function, a traceback...) inspect can use it to retrieve that
> information.

Aside from general concerns about increasing the size of class objects
(and most programs don't contain enough of those to make a big
difference) I don't immediately see anything that would prevent the
interpreter being modified to add file and line number information to
class objects as well. While the information wouldn't always be
present (types implemented in C, types created by calling the
metaclass constructor directly), it would help address the inspect
module bugs Steven illustrated.

I would agree with Carl that modifying __module__ in the way he
suggests is legitimate - if it breaks the inspect module, then it is
the inspect module that needs fixing (and/or better support from the
interpreter to help find the real source code).

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

Re: Embedding a literal "\u" in a unicode raw string.

[NickC]

On Feb 26, 8:45 am, rmano <[EMAIL PROTECTED]> wrote:
> BTW, 2to3.py should warn when a raw string (not unicode) with \u in
> it, I think.
> I tried it and it seems to ignore the problem...

Python 3.0a3+ (py3k:61229, Mar  4 2008, 21:38:15)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> r"\u"
'\\u'
>>> r"\uparrow"
'\\uparrow'
>>> r"\u005c"
'\\u005c'
>>> r"\N{REVERSE SOLIDUS}"
'\\N{REVERSE SOLIDUS}'
>>> "\u005c"
'\\'
>>> "\N{REVERSE SOLIDUS}"
'\\'

2to3.py may be ignoring a problem, but existing raw 8-bit string
literals containing a '\u' aren't going to be it. If anything is going
to have a problem with conversion to Py3k at this point, it is raw
Unicode literals that contain a Unicode escape.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How about adding rational fraction to Python?

[NickC]

On Mar 4, 7:11 am, Lie <[EMAIL PROTECTED]> wrote:
> On Mar 2, 11:36 pm, Paul Rubin  wrote:
> > > > Try with a=7, b=25
>
> > > They should still compare true, but they don't. The reason why they
> > > don't is because of float's finite precision, which is not exactly
> > > what we're talking here since it doesn't change the fact that
> > > multiplication and division are inverse of each other.
>
> > What?  Obviously they are not exact inverses for floats, as that test
> > shows.  They would be inverses for mathematical reals or rationals,
> > but Python does not have those.
>
> When I said multiplication and division are inverse, I was pointing
> out the fact that even though float's inexactness make them imperfect
> inverse, mult & div are still inverse of each other. In-practice, the
> inversing behavior is impossible unless we have a way to represent
> real number (which we don't), and the *workaround* to make them work
> is to do epsilon comparison.

A mildly interesting Py3k experiment:

Python 3.0a3+ (py3k:61229, Mar  4 2008, 21:38:15)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from fractions import Fraction
>>> from decimal import Decimal
>>> def check_accuracy(num_type, max_val=1000):
... wrong = 0
... for x in range(1, max_val):
... for y in range(1, max_val):
... wrong += (x / num_type(y)) * y != x
... return wrong
...
>>> check_accuracy(float)
101502
>>> check_accuracy(Decimal)
310013
>>> check_accuracy(Fraction)
0


The conclusions I came to based on running that experiment are:
- Decimal actually appears to suffer more rounding problems than float
for rational arithmetic
- Decimal appears to be significantly slower than Fraction for small
denominator rational arithmetic
- both Decimal and Fraction are significantly slower than builtin
floats

The increased number of inaccurate answers with Decimal (31% vs 10%)
is probably due to the fact that it is actually more precise than
float - for the builtin floats, the rounding error in the division
step may be cancelled out by a further rounding error in the
multiplication step (this can be seen happening in the case of ((1 /
3.0) * 3) == 1.0, where the result of the multiplication ends up being
1.0 despite the rounding error on division, due to the next smallest
floating value being 0.99989).

The speed difference between Decimal and Fraction is likely due to the
fact that Fraction can avoid actually doing any division most of the
time - it does addition and multiplication instead. The main reason
behind the overall speed advantage of builtin floats should hopefully
be obvious ;)

Regardless, the result of integer division is going to be a binary
floating point value in Py3k. For cases where that isn't adequate or
acceptable, the application should really be tightly controlling its
numeric types anyway and probably using a high performance math
library like numpy or gmpy instead of the standard numeric types (as
others have already noted in this thread).


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

Re: for-else

[NickC]

On Mar 4, 11:27 pm, [EMAIL PROTECTED] wrote:
>
> The meaning is explicit. While "else" seems to mean little there.
> So I may like something similar for Python 3.x (or the removal of the
> "else").

Consider a loop with the following form:

while 1:
  if :
<0-to-many times code block>
  else:
<0-to-1 times code block>
break

A break, return or exception in the 0-to-many times code block will
obviously skip over the 'else' part of that if statement - it will
only be executed if  evaluates as a false value. The above
code is actually equivalent to a normal Python while-loop:

while :
  <0-to-many times code block>
else:
  <0-to-1 times code block>

For loops aren't quite so straightforward since the termination
condition is tied up with the StopIteration exception, but the clause
keeps the same name as the corresponding clause on the while loop.
Thinking of it as break-else (as someone else posted) probably isn't a
bad way to look at the situation.

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

Re: PyCon Feedback and Volunteers (Re: Pycon disappointment)

[NickC]

On Mar 19, 6:07 am, Jeff Schwab <[EMAIL PROTECTED]> wrote:
> As I have never attended PyCon, the amount of entertainment already
> gleaned from this thread has wildly exceeded my expectations. :)  Are
> slides or notes from any of the presentations available online?  What
> was the topic of the well-received presentation from Google?

I'm mostly intrigued by the tantalising hints being dropped regarding
Steve Holden's Teach Me Twisted talk ;)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[NickC]

On May 26, 7:32 am, "Joe P. Cool" <[EMAIL PROTECTED]> wrote:
> I saw this "don't need it" pattern in discussions about the ternary
> "if..else" expression and about "except/finally on the same block
> level".
> Now Python has both.

if/else was added solely because people kept coming up with ways of
embedding a pseudo conditional inside expressions and writing buggy
code in the process. All it really saves you in practice is a bit of
vertical whitespace, so, no, you still don't need it - but if you
insist on doing it, at least there's now an easy way to do it
correctly.

except/finally on the same block level was trivial to implement once
the reference interpreter switched to an AST based compiler for 2.5.
If you look at the AST, you'll find that it still only has TryExcept
and TryFinally, so again, you still don't need except/finally on the
same block level - all the syntax allows you to do is omit the second
try: line and its associated indentation.

> Actually it is very useful to be able to
> distinguish
> between inside and outside. This is obvious for real world things e.g.
> your
> TV. Nobody likes to open the rear cover to switch the channel. Similar
> arguments apply to software objects. "data hiding" is a harsh name, I
> would
> call it "telling what matters". The need for this becomes
> indispensable in
> really big software packages like the Eclipse framework with approx.
> 10
> classes. If you cannot tell the difference between inside and outside
> you
> are lost.
>
> > In Python, the philosophy "we're all consenting adults here" applies.
>
> Please don't sell a missing feature as a philosophy. Say you don't
> need/want
> it. But don't call it philosophy.

Gosh, and here I thought treating programmers as non-idiots was
actually one of the guiding philosophies in the discussion on python-
dev. Good thing we have you here to tell us we're only imagining that.

> > You shouldn't pretend to know, at the time you write it, all the uses
> > to which your code will be put.
>
> It's *your* *decision* which uses will be available. Your explanation
> appears
> to me as a fear to decide.

Are you writing application code or library code? For application
code, you have a much greater idea of the uses for your code, so you
can be confident in your decision as to what should and should not be
visible. For library code, however, it's fairly common for a library
to provide something which is almost, but not quite, what the user
needs. Letting users poke around at their own risk is a nice courtesy
that can save them a lot of work in the long run.

So the decision to hide something is still made (by using an
underscore prefix), but an easy mechanism is provided for the library
user to override that decision.

> > If you want the users of your code to know that an attribute should
> > not be used as a public API for the code, use the convention of naming
> > the attribute with a single leading underscore.
>
> Littering your class definition with dozens of underscores is exactly
> the
> line noise we love to criticize in Perl.

Using underscores in names (leading or otherwise) separated by
plaintext keywords is a far cry from multiple different symbols that
mean different things in different contexts and can be chained
together fairly arbitrarily.

> > > Python advertises himself as a full OOP language, but why does it
> > > miss one of the basic principles of OOP?
>
> > Who taught you that enforced restrictions on attribute access was a
> > "basic principle" of OO?
>
> Nearly every introduction to OOP? Please don't tell me that
> encapsulation
> does not mean "enforced restriction". If the language has no syntactic
> support for encapsulation then it does not have encapsulation.

Module globals aren't visible outside the module without importing it.
Class attributes aren't visible outside the class without derefencing
it.
Instance attributes aren't visible outside an instance without
deferencing one.

*That* is the encapsulation/data hiding which OOP requires, and is the
kind which Python enforces. What you're asking for is encapsulation of
class and instance attributes based on the context in which the
dereferencing occurs (inside the class, inside a subclass of that
class, inside an instance of that class, inside an instance of a
subclass of that class, somewhere else entirely), and that has nothing
to do with the basics of OOP.

On the other hand, if you're so keen on this feature, perhaps you'd
like to make a concrete proposal regarding how you would like the
semantics to work in light of Python dynamic typing model. What will
it do when a method is invoked via the class dict rather than via
attribute retrieval? Can unbound methods access protected or private
attribute? How about descriptor get, set and delete methods? What
happens when a function is added to a class definition after creation
as a new method?

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

Re: Why does python not have a mechanism for data hiding?

[NickC]

On May 26, 2:49 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
> I am also bothered a bit by the seeming inconsistency of the rules for
> the single underscore. When used at file scope, they make the variable
> or function invisible outside the module, but when used at class
> scope, the "underscored" variables or functions are still fully
> visible. For those who claim that the client should be left to decide
> what to use, why is the client prohibited from using underscored
> variables at file scope?

They aren't - the only thing that won't see the underscore prefixed
names is "from x import *". If you do "import x" instead, all the
underscored names will be accessible as attributes of the module.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why does python not have a mechanism for data hiding?

[NickC]

On Jun 4, 4:09 am, "Russ P." <[EMAIL PROTECTED]> wrote:
> What is it about leading underscores that bothers me? To me, they are
> like a small pebble in your shoe while you are on a hike. Yes, you can
> live with it, and it does no harm, but you still want to get rid of it.

With leading underscores, you can see *at the point of dereference*
that the code is accessing private data. With a "this is private"
keyword you have no idea whether you're accessing private or public
data, because the two namespaces get conflated together.

I'll keep my pebble, thanks.

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

Re: Why does python not have a mechanism for data hiding?

[NickC]

On May 25, 8:01 pm, Fuzzyman <[EMAIL PROTECTED]> wrote:
> > Python was not really written with 'difficult' customers in mind ;-)
>
> True. It's extremely suited to what we do though.Minor difficulties
> like this are vastly outweighed by advantages. The difficulties are
> real though.

It's interesting to take a look at some of the work Brett Cannon has
done trying to come up with a sandbox for executing Python code that
actually manages to block access to dangerous functions like file() or
urllib.urlopen(). Powerful introspection capabilities and restricted
access to methods and attributes don't really play well together.

http://svn.python.org/view/python/branches/bcannon-objcap/securing_python.txt?rev=55685&view=markup

(I believe that work is on hiatus while he's been busy with other
projects, such as a more flexible Python-based reimplementation of the
import mechanism that would be make it possible to implement the
security restrictions needed to permit limited imports in a sandboxed
interpreter)

> > One could largely hide private vars with a program that substituted random
> > names for single _ names, and removed the doc strings for functions,
> > classes, and methods with such names.
>
> We need to *use* those names to display the spreadsheet once the
> calculation has finished (and their code has run).
>
> > Such a program could even put such names in a separate module imported as
> > '_private_do_not_use_'.
>
> Splitting more of the functionality out is probably part of the best
> solution.

Yeah, at this point your only hope is going to be making them go
through such wild contortions to get at the internal data they think
better of it. Actually blocking all access to something written in
Python is fairly tough (you generally need an extension class written
in non-Python code that hides access to certain attributes).

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

Re: Why does python not have a mechanism for data hiding?

[NickC]

On Jun 4, 4:41 pm, Antoon Pardon <[EMAIL PROTECTED]> wrote:
> Guido has been known to change his mind, which is an admirabele quality,
> but it does show that at some point he rejected a good idea or accepted
> a bad idea.

And sometimes the person that talked him into accepting the bad idea
in the first place ends up agreeing with him when he eventually
rejects it ;)

Cheers,
Nick.

P.S. Read the list of references in PEP 343 if you want to know what
I'm talking about *cough*

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

Re: Why does python not have a mechanism for data hiding?

[NickC]

On Jun 4, 9:24 pm, Paul Rubin <http://[EMAIL PROTECTED]> wrote:
> NickC <[EMAIL PROTECTED]> writes:
> > if/else was added solely because people kept coming up with ways of
> > embedding a pseudo conditional inside expressions and writing buggy
> > code in the process. All it really saves you in practice is a bit of
> > vertical whitespace, so, no, you still don't need it - but if you
> > insist on doing it, at least there's now an easy way to do it
> > correctly.
>
> Come on, it's more than vertical whitespace, it's extraneous variables
> and sometimes even extraneous functions and function call overhead.
> And Python is supposed to be unbureaucratic.  People kept looking for
> ways to write conditional expressions instead of spewing the logic
> across multiple statements for a reason: the code is often cleaner
> that way.

True, but it really was the multitude of buggy workarounds for the
lack of a ternary expression that sealed the deal, rather than the
benefits of ternary expressions in their own right :)

Given that I personally use ternary expressions solely as the right
hand side of an assignment statement, the reduction in vertical
whitespace usage really is the only thing they gain me. I guess if you
embedded them as an argument to a function call or other more
complicated expression then there may be additional savings. I prefer
not to do that though, since such things can get quite difficult to
parse mentally when reading them later.

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

Re: Why does python not have a mechanism for data hiding?

[NickC]

On Jun 4, 9:56 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> Those unit tests should *not*, though, exercise anything but the
> public API, otherwise they're breaking encapsulation. Their assertion
> should continue to be just as true after a refactoring of the internal
> components as before.

Python must have bad unit tests then - the CPython test suite
explicitly tests private methods all the time.

There's actually an extremely good reason for doing it that way: when
the implementation of an internal method gets broken, the unit tests
flag it explicitly, rather than having to derive the breakage from the
breakage of 'higher level' unit tests (after all, you wouldn't factor
something out into its own method or function if you weren't using it
in at least a couple of different places).

Black box testing (testing only the public API) is certainly
important, but grey box and white box testing that either exploits
knowledge of the implementation when crafting interesting test cases,
or explicitly tests internal APIs can be highly beneficial in
localising faults quickly when something does break (and as any
experienced maintenance programmer will tell you, figuring out what
you actually broke is usually harder than fixing it after you find it).
--
http://mail.python.org/mailman/listinfo/python-list

Re: Finally had to plonk google gorups.

[NickC]

Hmm, according to this thread I probably shouldn't bother even trying
to contribute to c.l.p discussions that are highlighted in the Python-
URL announcements, even in cases where I think a core developer's
perspective may be of interest. As someone that only posts here
rarely, and uses Google Groups with a Gmail address to do so, it
sounds like I'll be kill-filed by a lot of people regardless of the
contents of what I post.

*shrug* Ah well, such is life.

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

Re: Java or C++?

[NickC]

On Apr 15, 1:46 pm, Brian Vanderburg II <[EMAIL PROTECTED]>
wrote:
> This will automatically call the constructors of any contained objects
> to initialize the string.  The implicit assignment operator
> automatically performs the assignment of any contained objects.
> Destruction is also automatic.  When 'p1' goes out of scope, during the
> destructor the destructor for all contained objects is called.

Yeah, C++ does try to be helpful, and all of those automatic copy
constructor, assignment operator and destructor implementations screw
up royally when confronted with pointers (and being able to use
pointers is basically the whole reason for bothering to write anything
in C or C++ in the first place). Code which relies on these default
method implementations is almost certain to be rife with memory leaks
and double-free bugs. So instead of being a convenience, they become a
painfully easy way of writing code that silently does some very, very
wrong things.

Other things like methods (including destructors!) being non-virtual
by default also make C++ code annoyingly easy to get wrong (without it
obviously looking wrong).

The whole design of C++ is riddled with premature optimisation of
speed and memory usage in the default settings, instead of choosing
safe defaults and providing concise ways of allowing the programmer to
say "I know optimisation X is safe here, please use it".

And the result? Any serious project in the language has to adopt it's
own techniques for avoiding all those traps, and those techniques are
likely to eliminate any supposed optimisations provided by the choices
of the C++ committee, while filling a code base with boilerplate that
only exists for the purpose of working around defects in the language
design (Scott Meyers has written at length about the worst of these
issues, far more clearly and eloquently than I ever could [1]).

That said, C++ code has one *huge* benefit over ordinary C code, which
is scope-controlled deletion of objects, and the associated Resource-
Acquisition-Is-Initialisation model. Even without using exceptions
(although those are handy as well), RAII is an excellent way of
guaranteeing that memory is freed, files are closed, or other
resources are released when a block of code is finished. RAII was
actually one of the inspirations behind the final form of PEP 343's
with statement.

Cheers,
Nick.

[1]http://www.amazon.com/Effective-Specific-Addison-Wesley-
Professional-Computing/dp/0201924889
-- 
http://mail.python.org/mailman/listinfo/python-list

How to Embed PHP in HTML print

[NickC]

I am running a Python application under apache web server, executing as a 
cgi script.  Most of the output is print statements that write HTML.

I'd like to embed some PHP code within the HTML.  The PHP is a gallery 
plugin script that talks to the core photo gallery application, written in 
php.

The idea is that my python app can display a random image from a photo 
album, using the photo gallery application's plugin script.

If I do: 'print ""', it doesn't work. I imagine because the 
web server never sees it as php code.

Is there a way to do this?

Some possible ideas:
Is there a way I can get python to call functions within a PHP app?
Perhaps write the plugin in a separate script in PHP, and include that 
page within my output so that apache recognises the page inclusion?  How 
to get apache to pay attention to the output so it "wakes up" and does 
some server-side includes?

Many thanks for any help.
-- 
NickC
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to Embed PHP in HTML print

[NickC]

On Sun, 24 Jan 2010 10:37:51 +, Duncan Booth wrote:

> content with ajax. Alternatively, use urllib in Python to retrieve a
> page from the Apache server and insert that into its own output: that

Thanks for hint on urllib.  I shake my head in amazement with python 
sometimes.  I'll write it here:

print urllib.urlopen('http://myserver.com/phpscript.php').read()

That's it.  *One* line.

The output from the php script is:



and the one-liner seamlessly prints that to insert it into the html output.

And I thought it would be hard; I should have known better.


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

Create object from variable indirect reference?

[NickC]

I can't seem to find a way to do something that seems straighforward, so I 
must have a mental block.  I want to reference an object indirectly 
through a variable's value.

Using a library that returns all sorts of information about "something", I 
want to provide the name of the "something" via a variable (command line 
argument).  The something is a class in the library and I want to 
instantiate an object of the class so I can start querying it.  I can't 
figure out how to pass the name of the class to the library.

Or, put another way, I can't figure out how to indirectly reference the 
value of the command line argument to create the object.

To make it clearer, it's roughly equivalent to this in bash:
 Sun="1AU" ; body=Sun; echo ${!body} --> outputs "1AU". 

command line:
$ ./ephemeris.py Moon

code:
import ephem
import optparse

# various option parsing (left out for brevity), 
# so variable options.body contains string "Moon",
# or even "Moon()" if that would make it easier.

# Want to instantiate an object of class Moon.
# Direct way:
moon1 = ephem.Moon()
# Indirect way from command line with a quasi bashism that obviously fails:
moon2 = ephem.${!options.body}()

Can someone point me in the right direction here?

(The library is PyEphem, an extraordinarily useful library for anyone 
interested in astronomy.)

Many thanks,

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

Re: Create object from variable indirect reference?

[NickC]

Many thanks for the replies.  getattr() works great:

>>> name='Moon'
>>> m2 = getattr(ephem,name)()
>>> m2.compute(home)
>>> print ephem.localtime(m2.rise_time)
2009-11-11 01:30:36.02

shows the moon will rise at 1:30am localtime tonight at my home location.

Excellent.

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

Vim breaks after Python upgrade

[NickC]

Perhaps OT, but I figure here is where people have seen this commonly.

I upgraded Python from my distro's default of 2.5.2 to 2.6.2.  Vim is now 
complaining every startup about missing  libraries, presumably as 
some plugins run some python code on initialisation.  I'm guessing vim is 
complaining as it was compiled with python support, and that was 2.5.2, 
and the compiled-in python library locations no longer exist.

I compiled a new vim, so things are ok-ish, but now my system is even 
further away from standard distro.  I'm also a little surprised vim is so 
clunky as to use hard-coded locations.  Do I really have to compile a new 
vim every python upgrade?

'strings vim' shows some ascii that could be the python library 
locations.  Being quite ignorant of how the linux loader works, could I in 
future use sed on the vim binary to change every string of "2.5.2" to 
"2.6.2", or are the library locations used by the loader coded in binary 
rather than ascii (and so, harder to find)?

Thanks,

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

Re: Vim breaks after Python upgrade

[NickC]

On Tue, 17 Nov 2009 13:46:25 -0500, Nick Stinemates wrote:

> At least with Gentoo, there's a command to recompile all of the plugins
> you have installed when upgrading python versions.
> 
> Your issue is probably related to that. I don't think VIM uses hardcoded
> locations for scripts at the core.
> 
> If you have any specific questions about the errors you're receiving,
> feel free to submit to the VIM mailing list or stop by the IRC channel:
> #vim on irc.freenode.org
> 

Ok, thanks.  I'm sorry for calling vim clunky; the choice of words 
probably reflected my disbelief at the time.

FWIW, sed'ing 's:2\.5:2\.6:g' doesn't work.   It does change some strings, 
but not (apparently) the numbers that matter.


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

Structured programming with optionParser

[NickC]

I'm writing a short (200 lines) script that has half-a-dozen parameter
options, and using optionParser to process the options.

I try to write well-written procedural programmes with functions doing one
thing well, and so on.  The problem I'm getting is that, inevitably, the
function that uses OptionParser ends up doing all the work.

So, I have a brief 6-line main() that calls other functions, a setup(), a
couple of ancillary functions, and a whopping doOptionParsing() that is
over 100 lines long.  doOptionParsing is doing all the work.

I'm struggling to see how you could refactor the option parsing function.
After all, it has to process the options, so it has to do all the setup
for those options, and then process them.

Does anyone have some sort of design pattern or standard template approach
to doing option parsing?  Or perhaps should I make optionParser variables 
global?

Thanks,

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

Re: Structured programming with optionParser

[NickC]

On Mon, 30 Aug 2010 21:19:08 -0700, Michele Simionato wrote:

> Perhaps, I should give an example of using plac.

> 
> For more (including managing options, which I have not shown here) you
> should check the full documentation of plac. I have just uploaded
> release 0.7.2, which is required for this example to work.

Many thanks, very useful.



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