Sir,
I am a computer science student studying in India. I have maintained a good
academic record throughtout my engineering. I would like to associate myself
with GOOGLE. I will be glad if you let me know how to apply for GOOGLE
INTERSHIP.. given a chance i would prove to be an asset to your
firm.Yourhelp might provide a new dimension to my career. Please help.
Thank you
--
SILKY SINGH
Brett Cannon wrote:
> Can't you do this testing in your own checkout without committing the
> change until you have talked to python-dev about the idea of changing
> how all types are initialized?
CC to Python Dev
The discussion is about http://svn.python.org/view?rev=59042&view=rev
I've carefully studied the docs before I've committed the change. The
problem is a well documented compiler issue on Windows. The tp_base slot
can't be filled with a type on Windows when the module is compiled with
distutils.
On Unix the gcc can handle tp_base fine. Since most Python developers
are using Linux or Mac OS X and the file isn't covered by a unit test
nobody has noticed the problem
http://docs.python.org/dev/3.0/extending/newtypes.html#subclassing-other-ty…
"When filling out the PyTypeObject() for the Shoddy type, you see a slot
for tp_base(). Due to cross platform compiler issues, you can’t fill
that field directly with the PyList_Type(); it can be done later in the
module’s init() function."
I've changed it for two reasons:
* The xxmodule.c file is an example and template for developers. It's
giving a bad example and it leads to code that doesn't compile on Windows.
* I'm working on a very basic unit test to test
distutils.core.Extension. I've chosen xxmodule and xxsubtype for the tests.
I hope I didn't step over a line with the change. I didn't change the
files w/o consulting the documentation first.
Christian
For another project (see my previous email on named tuples), I needed to
represent procedure signatures, and use them to expand arguments into the
dictionary of values that exists when execution of a procedure starts. To my
surprise, this capability didn't seem to be provided by the Python library,
even though it clearly is present within the Python system somewhere.
So I wrote a Signature class. Instances of the class represent all the
information present between the parentheses of a procedure definition.
Properties are provided to get the information out, and an expand_args method
can be called to expand arguments into a dictionary. This expand_args method
implements (if I've done it right) the argument conversion part of section
5.3.4 of the Python Reference Manual (http://docs.python.org/ref/calls.html).
I've put the code below, but I wonder if the real solution is just to create an
interface to already-existing capability? It occurs to me that the
implementation is likely to be in the interpreter itself and not written in
Python.
One possible improvement (and I'm not sure it's better, so I'm just putting it
out there): perhaps expand_args should be renamed to __call__. Then essentially
a Signature object would be a procedure whose body is just "return locals ()".
class Signature (object):
def __init__ (self, argnames,
excessargs=None, excesskeys=None, defaults=None):
self.__argnames = tuple (argnames)
self.__excessargs = excessargs
self.__excesskeys = excesskeys
if defaults is None:
defaults = {}
self.__defaults = dict (defaults)
@property
def argnames (self):
return self.__argnames
@property
def excessargs (self):
return self.__excessargs
@property
def excesskeys (self):
return self.__excesskeys
def defaults (self):
return dict (self.__defaults)
def expand_args (self, *args, **keys):
# Start with defaults
result = self.defaults ()
# Assign positional arguments
for i in range (min (len (args), len (self.argnames))):
result[self.argnames[i]] = args[i]
# Assign keyword arguments
for arg in self.argnames:
if arg in keys:
if arg in result:
raise TypeError
result[arg] = keys[arg]
del keys[arg]
# Check for missing arguments
for i in range (len (args), len (self.argnames)):
if not self.argnames[i] in result:
raise TypeError
# Excess positional arguments (*args parameter)
if self.excessargs is None:
if len (args) > len (self.argnames):
raise TypeError
else:
result[self.excessargs] = args[len (self.argnames):]
# Excess keyword arguments (**keys parameter)
if self.excesskeys is None:
if keys:
raise TypeError
else:
result[self.excesskeys] = keys
return result
Isaac Morland CSCF Web Guru
DC 2554C, x36650 WWW Software Specialist
I am finding myself often doing for loops over a subset of a list, like:
for r in results:
if r.numNodes != numNodes:
continue
# do something with r
It would be nice if the plain for loop was as flexible as list
comprehensions and allowed an optional if clause, like this:
for r in results if r.numNodes == numNodes:
# do something with r
Has this idea come up before? Does anyone else like this idea?
--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert