Class: @property -> .__dict__

[Ulrich]

Good morning,

I wonder if someone could please help me out with the @property
function as illustrated in the following example.

class te():
def __init__(self):
self.a = 23
@property
def b(self):
return 2 * self.a


t = te()
In [4]: t.a
Out[4]: 23

In [5]: t.b
Out[5]: 46

#works asexpected so far, now let's have a look into t.__dict__
In [6]: t.__dict__
Out[6]: {'a': 23}
-> b does not show up.

Could anyone please explain me why this does not work / how to get b
into .__dict__ / hint me to an explanation?

Thanks a lot in advance!

Cheers,

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

Re: Class: @property -> .__dict__

[Steven D'Aprano]

On Fri, 16 Dec 2011 00:52:11 -0800, Ulrich wrote:

> Good morning,
> 
> I wonder if someone could please help me out with the @property function
> as illustrated in the following example.
> 
> class te():
> def __init__(self):
> self.a = 23
> @property
> def b(self):
> return 2 * self.a
[...]
> Could anyone please explain me why this does not work / how to get b
> into .__dict__ / hint me to an explanation?

b is a property object. Like any other assignment inside the body of the 
class, it is shared across all instances, so you won't find it in the 
instance's personal dict. You will find it in the shared class dict.

t.__dict__['b']  # not found
te.__dict__['b']  # will return the property object

(By the way: it is the usual convention to start the name of a class with 
initial capital, so Te would be a better name.)

To get something into the instance dict, you need to assign it onto the 
instance:

t.x = 42  # puts 'x':42 into t.__dict__


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

Re: Class: @property -> .__dict__

[Ulrich]

On Dec 16, 10:03 am, Steven D'Aprano  wrote:
> On Fri, 16 Dec 2011 00:52:11 -0800, Ulrich wrote:
> > Good morning,
>
> > I wonder if someone could please help me out with the @property function
> > as illustrated in the following example.
>
> > class te():
> >     def __init__(self):
> >         self.a = 23
> >     @property
> >     def b(self):
> >         return 2 * self.a
> [...]
> > Could anyone please explain me why this does not work / how to get b
> > into .__dict__ / hint me to an explanation?
>
> b is a property object. Like any other assignment inside the body of the
> class, it is shared across all instances, so you won't find it in the
> instance's personal dict. You will find it in the shared class dict.
>
> t.__dict__['b']  # not found
> te.__dict__['b']  # will return the property object
>
> (By the way: it is the usual convention to start the name of a class with
> initial capital, so Te would be a better name.)
>
> To get something into the instance dict, you need to assign it onto the
> instance:
>
> t.x = 42  # puts 'x':42 into t.__dict__
>
> --
> Steven

Hi Steven,

Thanks a lot for your quick and helpful answer!


This would imply that I have to search in the dict of the class and
the dict of the instance. - works nicely.

I wonder if there is somewhere a "merge of the two" already available.

In the meantime, I came across dir()
In [7]: dir(t)
Out[7]: ['__doc__', '__init__', '__module__', 'a', 'b']

This seems to return 'a' and 'b', but now crashes

@property
def attributelist(self):
# find all attributes to the class that are of type numpy
arrays:
return [attr for attr in self.__dict__ if
isinstance(getattr(self, attr), numpy.ndarray)]




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

Re: Class: @property -> .__dict__

[Ulrich]

On Dec 16, 10:11 am, Ulrich  wrote:
> On Dec 16, 10:03 am, Steven D'Aprano 
>
>
>
>
>
>
>
>
> +comp.lang.pyt...@pearwood.info> wrote:
> > On Fri, 16 Dec 2011 00:52:11 -0800, Ulrich wrote:
> > > Good morning,
>
> > > I wonder if someone could please help me out with the @property function
> > > as illustrated in the following example.
>
> > > class te():
> > >     def __init__(self):
> > >         self.a = 23
> > >     @property
> > >     def b(self):
> > >         return 2 * self.a
> > [...]
> > > Could anyone please explain me why this does not work / how to get b
> > > into .__dict__ / hint me to an explanation?
>
> > b is a property object. Like any other assignment inside the body of the
> > class, it is shared across all instances, so you won't find it in the
> > instance's personal dict. You will find it in the shared class dict.
>
> > t.__dict__['b']  # not found
> > te.__dict__['b']  # will return the property object
>
> > (By the way: it is the usual convention to start the name of a class with
> > initial capital, so Te would be a better name.)
>
> > To get something into the instance dict, you need to assign it onto the
> > instance:
>
> > t.x = 42  # puts 'x':42 into t.__dict__
>
> > --
> > Steven
>
> Hi Steven,
>
> Thanks a lot for your quick and helpful answer!
>
> This would imply that I have to search in the dict of the class and
> the dict of the instance. - works nicely.
>
> I wonder if there is somewhere a "merge of the two" already available.
>
> In the meantime, I came across dir()
> In [7]: dir(t)
> Out[7]: ['__doc__', '__init__', '__module__', 'a', 'b']
>
> This seems to return 'a' and 'b', but now crashes
>
> @property
> def attributelist(self):
>         # find all attributes to the class that are of type numpy
> arrays:
>         return [attr for attr in self.__dict__ if
> isinstance(getattr(self, attr), numpy.ndarray)]


hi again,

I must have hit the send accidently before finishing.

This attributelist should return me all attributes of type
numpy.ndarry.

if I replace it to
def attributelist(self):
 # find all attributes to the class that are of type numpy
arrays:
 return [attr for attr in dir(self) if
isinstance(getattr(self, attr), numpy.ndarray)]

it crashes going into some kind of endless loop.

Do you happen to have any idea?

thanks again!

cheers,

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

Re: AttributeError in "with" statement (3.2.2)

[Steven D'Aprano]

On Thu, 15 Dec 2011 19:39:17 -0500, Terry Reedy wrote:
[...]

After reading your post, I think I have worked out where our disagreement 
lines: you think that bound methods and instance methods are not the same 
thing, and that a function defined inside a class is different from a 
function outside of a class.

For example, you say:

> If so, the output is a *bound method*. In your example
> above, func is not an instance method and obj is not a bound method. It
> is simply an partially evaluated curried function or if you prefer, a
> bound function. Take you pick, or make up your own term, but it is NOT
> an instance method, 

and later on:

>> So what are methods? In Python, methods are wrappers around functions
>> which automatically pass the instance to the inner function object.
> 
> These are bound methods. The instance methods are the functions wrapped.

I am afraid you are mistaken. What you say may very well apply to other 
languages, but in Python, def creates functions no matter where you 
execute it. Always and without exception.

I admit to an earlier mistake: I thought that conversion from function to 
method occurred once, when the class statement was executed, but I was 
mistaken. Re-reading Raymond Hettinger's excellent article on the 
descriptor protocol reminded me that methods are created on an as-needed 
basis, at runtime.

Back to methods and def. So let's see what happens in Python 3.1:

>>> def spam(self):  # Clearly a function.
...pass
... 
>>> class K(object):
... def ham(self):  # Allegedly an instance method
... pass
... 

According to your various statements, spam is a function and ham is an 
instance method. Merely storing a outside function inside a class doesn't 
create an instance method, it creates what you call a bound method 
(although I'm unclear what you think the difference is). So let's see 
what happens when we compare an alleged "bound method that is not an 
instance method" with an actual instance method:

>>> K.spam = spam
>>> type(K.spam) is type(K.ham)
True

Their types are identical. We get the same thing when we compare an 
actual function with a function object created inside a class, which you 
claim is actually an instance method:

>>> type(spam) is type(K.__dict__['ham'])  # Bypass descriptor protocol
True

Nor is there any difference in type between bound and unbound methods: 
they are both instance methods differing only in whether or not they have 
the first argument "self" available. Bound is an adjective, not part of 
the type: small method, obfuscated method, buggy method, or bound method.

Python 3 no longer uses unbound methods, since they are functionally 
identical to the unwrapped function, so this snippet is from Python 2.6:

py> k = K()
py> type(k.ham) is type(K().ham)  # bound vs bound
True
py> type(k.ham) is type(K.ham)  # bound vs unbound
True


In Python, instance methods are wrappers around function objects; they 
are created on call, and generally do not exist *anywhere* until needed, 
or if you store a reference to them.

>>> k = K()
>>> a = k.ham
>>> b = k.ham
>>> a is b
False

Under normal circumstances, the only persistent object is the function, 
which you can extract from the (class or instance) __dict__ or the method 
wrapper:

>>> a.__func__ is K.__dict__['ham']
True

Methods are created by the descriptor protocol: when you use the normal 
a.b syntax to access K.__dict__['ham'], the metaclass calls the __get__ 
method of function ham. If you call it from an instance, you get a method 
object bound to that instance. If you call it from the class, in Python 2 
you get a method object not bound to an instance, in Python 3 you get the 
function without a wrapper.

[Aside: class methods and static methods also work the same way, via 
__get__ and the descriptor protocol, but behave differently. Class 
methods reuse the instance method type, which is somewhat confusing, and 
static methods just return the function.]

So, what the hell does all this mean in practice?

Most of the time, absolutely nothing. That's why I started this 
discussion with the disclaimer that I didn't think it was worth changing 
the (not quite right) definition of "method" you originally quoted. Most 
of the time, we only access methods via the instance.method syntax, which 
gives us an instance method. By the principle that if it quacks like a 
duck and swims like a duck, it is good enough to call it a duck, I'm 
happy to agree that ham here is a method:

class K:
def ham(self): pass 

That covers 99% of all use-cases and is good enough for most situations.

But the OP ran into one of those edge cases in the 1%, where things are 
not so simple. He was attempting to create an instance method called 
"__exit__" and store it in the instance __dict__ instead of the class 
__dict__. This is a perfectly reasonable thing to do, but there are two 
gotchas to it:

  * The descriptor protocol doesn't get used for instance 
lookups. That's why

Re: Class: @property -> .__dict__

[Peter Otten]

Ulrich wrote:

> if I replace it to
> def attributelist(self):
>  # find all attributes to the class that are of type numpy
> arrays:
>  return [attr for attr in dir(self) if
> isinstance(getattr(self, attr), numpy.ndarray)]
> 
> it crashes going into some kind of endless loop.
> 
> Do you happen to have any idea?

dir(self) finds an attribute named "attributelist", getattr(self, 
"attributelist") then tries to calculate the value of that attribute, 
invokes dir(self) which finds an attribute named "attributelist" and so on 
ad infinitum or the stack overflows. Try (untested)

@property
def attributelist(self):
return [attr for attr in dir(self) if attr != "attributelist" and
isinstance(getattr(self, attr), numpy.ndarray)]

to avoid the infinite recursion.

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

Re: Class: @property -> .__dict__

[Thomas Rachel]

Am 16.12.2011 09:52 schrieb Ulrich:


Could anyone please explain me why this does not work / how to get b
into .__dict__ / hint me to an explanation?


b is not a data element of the particular instance, but it lives in the 
class. It is, roughly spoken, a "kind of method", just to be used 
without calling. These things are called "data descriptors" 
(http://docs.python.org/reference/datamodel.html#descriptors).


t.b is internally reflected to te.__dict__['b'].__get__(t, te) in order 
to call the __get__ method of the property object. This is done on every 
call and the value is, in your case, derived from the instance value a.


HTH,

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

modifying a time.struct_time

[Ulrich Eckhardt]

Hi!

I'm trying to create a struct_time that is e.g. one year ahead or a 
month back in order to test some parsing/formatting code with different 
dates.


Now, the straightforward approach is

  t = time.localtime()
  t.tm_year += 1

This fails with "TypeError: readonly attribute". This kind-of makes 
sense, as an immutable object allows you to use it as key in a dict.



The second approach is this:

  l = list(t) # convert to a sequence
  l[0] += 1 # increment year
  t = time.struct_time(l) # convert to a struct_time

This works but is ugly, because the code relies on the order inside the 
list and uses magic numbers to access them. The order is AFAICT not 
accessible programmatically but only documented, and not even in a way 
that makes clear that it is part of the API and as such actualy 
guaranteed. I could try to assert that the indices match using "if l[0] 
is t.tm_year", but this is still ugly.



The next approach I tried was to simply create a derived class:

  class my_time(time.struct_time):
  pass

This fails again with "TypeError: Error when calling the metaclass 
bases, type 'time.struct_time' is not an acceptable base type. I could 
try to encapsulate a struct_time and delegate attribute access to it in 
order to do this, but it also seems overkill. Also, using an immutable 
type as a baseclass and delegating access to members seems like hackery 
to me, prone to fail in situations where it is least expected.



Then I tried duck typing. If it quacks like a duck, it better not be a 
crocodile! This looks like this:


  struct my_time(object): pass
  t = my_time()
  t.tm_year = 2012
  t.tm_month = 12
  t.tm... # other fields accordingly
  time.mktime(t)

This fails with "TypeError: argument must be 9-item sequence, not 
my_time". I thought about using a collections.namedtuple, because a 
namedtuple is a tuple and therefore also a sequence, but that only leads 
me back to the problem that time.mktime() takes a sequence and the order 
of the sequence is not accessible programmatically.



A last approach was to convert the thing to a dict and back. Alas, there 
is no conversion to a dict, otherwise


  d = dict(t)
  d['tm_year'] += 1
  t = time.struct_time(d)

would have been a straightforward approach.


Does anyone have a suggestion how to solve this elegantly and 
pythonically? Also, what I'm wondering is if the lack of a clear way 
should be considered a bug or not.



Cheers!

Uli

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

Re: modifying a time.struct_time

[Mazen Harake]

Hi,

Easiest way is to change the time to seconds, add as many seconds as a
year/month/week/day/hour/minutes represent and then transform it back.

E.g.

>>> time.time()
1324031491.026137
>>> time.time() + 3600 # Add an hour
1324035105.082003
>>> time.gmtime(time.time() + 3600)
time.struct_time(tm_year=2011, tm_mon=12, tm_mday=16, tm_hour=11,
tm_min=31, tm_sec=57, tm_wday=4, tm_yday=350, tm_isdst=0)
>>>

On 16 December 2011 10:45, Ulrich Eckhardt
 wrote:
> Hi!
>
> I'm trying to create a struct_time that is e.g. one year ahead or a month
> back in order to test some parsing/formatting code with different dates.
>
> Now, the straightforward approach is
>
>  t = time.localtime()
>  t.tm_year += 1
>
> This fails with "TypeError: readonly attribute". This kind-of makes sense,
> as an immutable object allows you to use it as key in a dict.
>
>
> The second approach is this:
>
>  l = list(t) # convert to a sequence
>  l[0] += 1 # increment year
>  t = time.struct_time(l) # convert to a struct_time
>
> This works but is ugly, because the code relies on the order inside the list
> and uses magic numbers to access them. The order is AFAICT not accessible
> programmatically but only documented, and not even in a way that makes clear
> that it is part of the API and as such actualy guaranteed. I could try to
> assert that the indices match using "if l[0] is t.tm_year", but this is
> still ugly.
>
>
> The next approach I tried was to simply create a derived class:
>
>  class my_time(time.struct_time):
>      pass
>
> This fails again with "TypeError: Error when calling the metaclass bases,
> type 'time.struct_time' is not an acceptable base type. I could try to
> encapsulate a struct_time and delegate attribute access to it in order to do
> this, but it also seems overkill. Also, using an immutable type as a
> baseclass and delegating access to members seems like hackery to me, prone
> to fail in situations where it is least expected.
>
>
> Then I tried duck typing. If it quacks like a duck, it better not be a
> crocodile! This looks like this:
>
>  struct my_time(object): pass
>  t = my_time()
>  t.tm_year = 2012
>  t.tm_month = 12
>  t.tm... # other fields accordingly
>  time.mktime(t)
>
> This fails with "TypeError: argument must be 9-item sequence, not my_time".
> I thought about using a collections.namedtuple, because a namedtuple is a
> tuple and therefore also a sequence, but that only leads me back to the
> problem that time.mktime() takes a sequence and the order of the sequence is
> not accessible programmatically.
>
>
> A last approach was to convert the thing to a dict and back. Alas, there is
> no conversion to a dict, otherwise
>
>  d = dict(t)
>  d['tm_year'] += 1
>  t = time.struct_time(d)
>
> would have been a straightforward approach.
>
>
> Does anyone have a suggestion how to solve this elegantly and pythonically?
> Also, what I'm wondering is if the lack of a clear way should be considered
> a bug or not.
>
>
> Cheers!
>
> Uli
>
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]

[Eelco]

On Dec 16, 3:58 am, MRAB  wrote:
> On 16/12/2011 02:14, alex23 wrote:
>
> > Eelco  wrote:
> >> To tie it back in with python language design; all the more reason
> >> not to opt for pseudo-backwards compatibility. If python wants a
> >> remainder function, call it 'remainder'. Not 'rem', not 'mod', and
> >> certainly not '%'.
>
> Python has "def", "del", "int", "str", "len", and so on. "rem" or "mod"
> (Ada has both, I believe) would be in keeping with the language.

def and del are keywords, and thus in another league. Having shorthand
notation for types is somewhat defensible, though I believe I would
prefer a more verbose form there too; how often to you encounter these
in python anyway? len is a bit of an eeysore to me too; I understand
having it as a builtin is a matter of optimization or something, but I
do wish we would be given the option of just saying list.length

> > Good luck with the PEP.
>
> >> Its the more pythonic way; a self-describing name, rather than
> >> poorly defined or poorly understood cryptology.
>
> > "Although practicality beats purity."
>
> > I'm still utterly agog that anyone finds the operator % confusing.
>
> In financial circles it could be an operator for calculating
> percentages, eg. "5 % x" would be 5 percent of x.
>
> It's an oddity, but an established one. :-)

Well yes, thats the only argument ive heard so far that resonated with
me. These syntax details are not a very big deal, and backwards
compatibility with yourself is quite a big deal. Its nice to keep
'what ought to have been done' and 'what ought we to do' seperate in
such discussions. Im not sure we ought to change these syntax details
(I mean relating to mod and such), but I am quite sure of what I would
have done if I could go back in time.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]

[Eelco]

On Dec 16, 6:30 am, alex23  wrote:
> On Dec 16, 3:01 pm, Chris Angelico  wrote:
>
> > And I would be most sorry to see % renamed to mod in Python.
>
> > "Hello, %s! My favourite number is %d." mod ("Fred",42)   # This just
> > looks wrong.
>
> Finally we can give this operator a more fitting name - I propose
> 'inject' - and put an end to this insane desire to leverage off pre-
> existing knowledge of other languages.
>
> Furthermore, I suggest that no two languages should ever have
> identical semantics, just to avoid potential confusion.
>
> New concepts for all!

Dont get me started on that one. Its that I never work with strings...

'leverage of pre-existing knowledge'... I would hardly call the
particular names of functions the knowledge about a language.

The only argument that bears any weight with me is backwards
compatibility with itself. Pseudo-backwards compatibility with other
languages, I couldnt not care less for.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: modifying a time.struct_time

[Steven D'Aprano]

On Fri, 16 Dec 2011 10:45:22 +0100, Ulrich Eckhardt wrote:

> Hi!
> 
> I'm trying to create a struct_time that is e.g. one year ahead or a
> month back in order to test some parsing/formatting code with different
> dates.
[...]
> The second approach is this:
> 
>l = list(t) # convert to a sequence
>l[0] += 1 # increment year
>t = time.struct_time(l) # convert to a struct_time
> 
> This works but is ugly, because the code relies on the order inside the
> list and uses magic numbers to access them. The order is AFAICT not
> accessible programmatically but only documented, and not even in a way
> that makes clear that it is part of the API and as such actualy
> guaranteed. I could try to assert that the indices match using "if l[0]
> is t.tm_year", but this is still ugly.

Feel free to propose a feature enhancement to time.struct_time, but the 
order of the fields is stable and won't change. So ugly or not, that way 
is guaranteed to work.


[...]
> Then I tried duck typing. If it quacks like a duck, it better not be a
> crocodile! This looks like this:
> 
>struct my_time(object): pass

"struct"?


[...]
> Does anyone have a suggestion how to solve this elegantly and
> pythonically? Also, what I'm wondering is if the lack of a clear way
> should be considered a bug or not.

Not a bug, but it does seem a very old and inelegant API more suited to 
hairy C programmers gathered around a smokey fire in a cave chewing on 
old dinosaur bones, and not worthy of space-age Python coders flying 
around on anti-gravity belts.



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

Re: modifying a time.struct_time

[Chris Angelico]

On Fri, Dec 16, 2011 at 8:45 PM, Ulrich Eckhardt
 wrote:
> I'm trying to create a struct_time that is e.g. one year ahead or a month
> back in order to test some parsing/formatting code with different dates.

Do you need it to be one exact calendar year, or would it make sense
to add/subtract integers from a Unix time?

t = time.time() + 365*86400   # Not actually a year ahead, it's 365 days ahead
t = time.localtime(t)  # if you want a struct_time

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

Re: modifying a time.struct_time

[Tim Golden]

On 16/12/2011 10:44, Steven D'Aprano wrote:
[ on time.struct_time ]


Not a bug, but it does seem a very old and inelegant API more suited to
hairy C programmers gathered around a smokey fire in a cave chewing on
old dinosaur bones, and not worthy of space-age Python coders flying
around on anti-gravity belts.


+1 QOTW

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

GlobalLogic PYTHON/JAVA positions

[Richa Sinha]

Hi All ,

Trust you doing well..

GlobalLogic is looking for highly skilled *Python Developers/Sr.Developers* ,
*JAVA DEVELOPERS/Sr. Developers* for one of our strategic engagements with *
GOOGLE. *

Following are the details:

>
>>  *Python Developer(s)/Sr. Developers*
>>
>>
>>
>> Experience: 1-5 Yrs
>>
>> Min Qualification: BS/BE/B.Tech/MCA Regular
>>
>> Job Location: Client site- Gurgaon (India)  Google office
>>
>  Positions: 20
>>
>> * *
>>
>> *Requisites:*
>>
>>
>>- * *   OOPS concepts in Python
>>- Exposure to python as a language , not only as a script
>>-  Good knowledge of File handling and XML parsing
>>-Good to have experience in Multithreading in python.
>>- Usage of inbuilt data types.
>>-Implementation Of various design patterns
>>- Should have Worked On python specific packages
>>- Should have Worked On python specific frameworks like
>>django, zope,
>>- Exposure to middlewares, decorators, etc.
>>- He should have worked on web apps instead of desktop apps.
>>
>> For Python: Send updated CV to richa.si...@globallogic.com

> *
>> *
>>
>> *JAVA Positions: *
>>
>> *
>> *
>>
>> *Min Qualification*: BS/BE/B.Tech/MCA or equivalent.
>>
>> *Location* – Client site- Gurgaon (India) Google office
>>
>> *Positions: 10*
>> *Experience*: Total work exp should be 2 - 5 yrs
>>
>>- Work experience and relevant experience in internet architecture
>>and software development.
>>- Fluency in at least two of the following languages: Java,
>>JavaScript.
>>- Expertise in object-oriented programming and design patterns
>>(primarily MVC).
>>- Hands on experience in database design, SQL and any ORM tool like
>>Hibernate/JDO etc.
>>- Experience in TDD based developmen.
>>
>>
>> *Desired Skills*:
>>
>>- Innovativeness; ability to think outside the box .
>>- Creativity and problem-solving ability .
>>- Very good communication skills; must be able to gather requirements
>>from potential users and discuss the requirements effectively with a
>>technical team of developers .
>>- Previous experience in developing web applications will be an added
>>advantage.
>>Working knowledge of linux environment is a plus.
>>- Previous experience of working with Google tools/gadgets is a big
>>plus.
>>
>> For Java : Send updated CV to ankit.bans...@globallogic.com


* Do visit* www.globallogic.com*

**Share this mail with your friends, alumni groups,communities etc., spread
the great opportunity :) *



-- 
Regards,
Richa Sinha | Talent Acquisition
*Leaders in Software R&D Services*
*www.globallogic.com* 
ARGENTINA |CHINA | INDIA | ISRAEL | UKRAINE | UK | USA
Office: +91-120-406-2378
http://www.youtube.com/watch?v=V4pwY800TII
-- 
http://mail.python.org/mailman/listinfo/python-list

ckjdlkfnl,ndf,nfd,fndfnkdnk mmdlssdlndnll; k; as; lkds sjdsljdlskjdsl; kdslksdl; ddlk

[D. Mohan M. Dayalan]

http;//123maza.com/48/moon670/
-- 
http://mail.python.org/mailman/listinfo/python-list

merging argparse parsers

[Andrea Crotti]

I would like to have something like

merged_parser = LoggingParser() + OtherParser()

Which should create an argument parser with all the options composed.

Now for that I think I would need to subclass the argument, and something
fancy with the overloading.
The problem is that apparently there is no Argument class, but add_argument
just change the object internal data structures.

So the only alternative I see now is to do something like:
def add_project_argument(parser):
parser.add_argument('project_path',
help='paths of the project to run')

which is not very neat and modifies the object in place.
Any other ideas?
--
http://mail.python.org/mailman/listinfo/python-list

RE: Localhost client-server simple ssl socket test program problems

[Yang Chun-Kai]

> To: python-list@python.org
> From: li...@cheimes.de
> Subject: Re: Localhost client-server simple ssl socket test program problems
> Date: Thu, 15 Dec 2011 20:45:43 +0100
> 
> Am 15.12.2011 20:09, schrieb Yang Chun-Kai:
> > Server side error:
> > 
> > File "views.py", line 17, in 
> > connstream = ssl.wrap_socket(newsocket, server_side=True,
> > certfile="/etc/home/ckyang/PHA/testsslsocket/mypha.crt",
> > keyfile="/etc/home/ckyang/PHA/testsslsocket/mypha.key",
> > ssl_version=ssl.PROTOCOL_SSLv23)
> >   File "/usr/lib/python2.7/ssl.py", line 344, in wrap_socket
> > ciphers=ciphers)
> >   File "/usr/lib/python2.7/ssl.py", line 119, in __init__
> > ciphers)
> > ssl.SSLError: [Errno 336265218] _ssl..c:347: error:140B0002:SSL
> > routines:SSL_CTX_use_PrivateKey_file:system lib
> 
> This error is most likely caused by an encrypted private key. Python's
> SSL lib doesn't support encrypted private keys for sockets. You can
> encrypt the private key with
>> >>>I generate the server private key with "openssl genrsa -out mypha.key 
>> >>>2048".>>>But this seems the standard command to do it.>>>How do I get 
>> >>>the private key without encrypted ?>>>Or should I always do this and 
>> >>>encrypt it again to get it decrypted ?>>>If I use the encrypted key 
>> >>>and .csr to produce my certificate will that be different from 
>> >>>decrypted key?>>>Thanks.>>>Kay>>>
>openssl rsa -in /etc/home/ckyang/PHA/testsslsocket/mypha.key -out
> /etc/home/ckyang/PHA/testsslsocket/mypha-nopasswd.key
> 
> Christian
> 
> 
> -- 
> http://mail.python.org/mailman/listinfo/python-list
  -- 
http://mail.python.org/mailman/listinfo/python-list

Make a small function thread safe

[Brad Tilley]

Hey guys,

I have a C++ function that I'd like to replicate (as closely as
possible) in Python. Here's an example:

107 void increment_counter( unsigned int& counter )
108 {
109 boost::mutex::scoped_lock lock( counter_lock );
110 ++counter;
111 }

A thread locks the function on entrance and then releases it on exit.
What is the equivalent way to do this in Python?

Many thanks!

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

Re: Make a small function thread safe

[Tim Wintle]

On Fri, 2011-12-16 at 05:21 -0800, Brad Tilley wrote:
> 107 void increment_counter( unsigned int& counter )
> 108 {
> 109 boost::mutex::scoped_lock lock( counter_lock );
> 110 ++counter;
> 111 }


with counter_lock:
counter += 1


... where counter_lock is a threading.Lock instance.

(see docs for the threading module)

Tim

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

Re: modifying a time.struct_time

[Ulrich Eckhardt]

Am 16.12.2011 10:45, schrieb Ulrich Eckhardt:

I'm trying to create a struct_time that is e.g. one year ahead or a
month back in order to test some parsing/formatting code with different
dates.


There is something I stumbled across that helps and that is the datetime 
module, which seems more reasonably pythonic, and which allows 
operations on dates like adding a


Concerning the idea to use seconds, I'd rather not, because already the 
number of seconds per minute ranges from 60 to 62, and it doesn't get 
better with things like months (28...31 days), years (365...366 days) 
and all other types built upon them.


Considering the question if the current state is buggy, I'm definitely 
+1 on it. I do understand that this API is not going to change, but 
explicitly documenting in "help(time)" that the order is fixed and 
possibly making the order programmatically available are not changes but 
useful additions, IMHO. Also, conversion from/to a dict and perhaps a 
link to the datetime module would have saved me some futile attempts.


Thanks to all responders, I wish you a happy weekend!

Uli

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

Re: Make a small function thread safe

[Brad Tilley]

On Fri, Dec 16, 2011 at 8:33 AM, Tim Wintle wrote:

> On Fri, 2011-12-16 at 05:21 -0800, Brad Tilley wrote:
> > 107 void increment_counter( unsigned int& counter )
> > 108 {
> > 109 boost::mutex::scoped_lock lock( counter_lock );
> > 110 ++counter;
> > 111 }
>
>
> with counter_lock:
>counter += 1
>
>
> ... where counter_lock is a threading.Lock instance.
>
> (see docs for the threading module)




So something like this then:

import threading

shared_container = []
lock = threading.Lock()

class thread_example( threading.Thread ):

def __init__( self ):
threading.Thread.__init__ (self)

def run(t):
lock
shared_container.append(t.name)

# main

threads = []
for i in xrange(10):
thread = thread_example()
threads.append(thread)

for thread in threads:
thread.start()

for item in shared_container:
print item
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: modifying a time.struct_time

[Chris Angelico]

On Sat, Dec 17, 2011 at 12:32 AM, Ulrich Eckhardt
 wrote:
> Concerning the idea to use seconds, I'd rather not, because already the
> number of seconds per minute ranges from 60 to 62, and it doesn't get better
> with things like months (28...31 days), years (365...366 days) and all other
> types built upon them.

Right, which is why I asked how important the difference between "365
days" and "1 year" is. Obviously if your goal is one entire calendar
year, then you don't want to duplicate the work of figuring out how
many seconds that is.

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

Re: Make a small function thread safe

[Brad Tilley]

On Fri, Dec 16, 2011 at 9:24 AM, Brad Tilley  wrote:

>
>
> On Fri, Dec 16, 2011 at 8:33 AM, Tim Wintle wrote:
>
>> On Fri, 2011-12-16 at 05:21 -0800, Brad Tilley wrote:
>> > 107 void increment_counter( unsigned int& counter )
>> > 108 {
>> > 109 boost::mutex::scoped_lock lock( counter_lock );
>> > 110 ++counter;
>> > 111 }
>>
>>
>> with counter_lock:
>>counter += 1
>>
>>
>> ... where counter_lock is a threading.Lock instance.
>>
>> (see docs for the threading module)
>
>
>
>
> So something like this then:
>
> import threading
>
> shared_container = []
> lock = threading.Lock()
>
> class thread_example( threading.Thread ):
>
> def __init__( self ):
> threading.Thread.__init__ (self)
>
> def run(t):
> lock
> shared_container.append(t.name)
>
> # main
>
> threads = []
> for i in xrange(10):
> thread = thread_example()
> threads.append(thread)
>
> for thread in threads:
> thread.start()
>
> for item in shared_container:
> print item
>
>
Or perhaps run should look like this instead:

def run(t):
lock.acquire()
shared_container.append(t.name)
lock.release()

That seems a bit barbaric to me, not sure.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Make a small function thread safe

[Tim Wintle]

On Fri, 2011-12-16 at 09:24 -0500, Brad Tilley wrote:
> So something like this then:
> 
> import threading
> 
> shared_container = []
> lock = threading.Lock()
> 
> class thread_example( threading.Thread ):
> 
> def __init__( self ):
> threading.Thread.__init__ (self)
> 
> def run(t):
> lock
> shared_container.append(t.name)

should be:
  def run(t):
  with lock:
  shared_container.append(t.name)

(or lock.acquire() and lock.release() as you mentioned)

> # main
> 
> threads = []
> for i in xrange(10):
> thread = thread_example()
> threads.append(thread)
> 
> for thread in threads:
> thread.start()

you'll either need to lock again here, or join each thread:

for thread in threads:
  thread.join()

> for item in shared_container:
> print item 

Tim

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

Re: ERP with Supply chain management (incl. POS) and Customer relationship management ??? What's available?

[Grant Edwards]

On 2011-12-16, Gregory Ewing  wrote:
>> On Thu, Dec 15, 2011 at 5:54 AM, Anurag Chourasia
>>  wrote:
>> 
>>>I am building a POS/CRM (Loyalty Management) system as well.
>
> Is it just me, or does the phrase "Loyalty Management" have
> a faintly ominous ring to it?

Yea, sounds a bit like Newspeak -- maybe it's what the secret police
do under a dictatorship.

-- 
Grant Edwards   grant.b.edwardsYow! It's some people
  at   inside the wall!  This is
  gmail.combetter than mopping!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Make a small function thread safe

[Brad Tilley]

On Dec 16, 9:36 am, Tim Wintle  wrote:

> should be:
>       def run(t):
>           with lock:
>               shared_container.append(t.name)
>
> (or lock.acquire() and lock.release() as you mentioned)


Thanks Tim. The with statement is closer to the C++ code (IMO) more so
than the explicit acquire() and release() so I'll use that approach. I
appreciate your advice.

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

Re: ERP with Supply chain management (incl. POS) and Customer relationship management — What's available?

[Emile van Sebille]

On 12/15/2011 6:43 AM Alec Taylor said...

On Thu, Dec 15, 2011 at 5:54 AM, Anurag Chourasia
  wrote:

Hi Alec,

I am building a POS/CRM (Loyalty Management) system as well.

So far, the best I could find to use as a base



OpenERP?

Emile

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

Re: Class: @property -> .__dict__

[Ian Kelly]

On Fri, Dec 16, 2011 at 2:32 AM, Peter Otten <__pete...@web.de> wrote:
> Ulrich wrote:
>
>> if I replace it to
>> def attributelist(self):
>>          # find all attributes to the class that are of type numpy
>> arrays:
>>          return [attr for attr in dir(self) if
>> isinstance(getattr(self, attr), numpy.ndarray)]
>>
>> it crashes going into some kind of endless loop.
>>
>> Do you happen to have any idea?
>
> dir(self) finds an attribute named "attributelist", getattr(self,
> "attributelist") then tries to calculate the value of that attribute,
> invokes dir(self) which finds an attribute named "attributelist" and so on
> ad infinitum or the stack overflows. Try (untested)
>
> @property
> def attributelist(self):
>    return [attr for attr in dir(self) if attr != "attributelist" and
>            isinstance(getattr(self, attr), numpy.ndarray)]
>
> to avoid the infinite recursion.

Or remove attributelist from the class (it feels more like a generic
function than a class property to me) or make it a method instead of a
property.
-- 
http://mail.python.org/mailman/listinfo/python-list

re.sub(): replace longest match instead of leftmost match?

[John Gordon]

According to the documentation on re.sub(), it replaces the leftmost
matching pattern.

However, I want to replace the *longest* matching pattern, which is
not necessarily the leftmost match.  Any suggestions?

I'm working with IPv6 CIDR strings, and I want to replace the longest
match of "(:|$)+" with ":".  But when I use re.sub() it replaces
the leftmost match, even if there is a longer match later in the string.

I'm also looking for a regexp that will remove leading zeroes in each
four-digit group, but will leave a single zero if the group was all
zeroes.

Thanks!

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

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

Re: re.sub(): replace longest match instead of leftmost match?

[Devin Jeanpierre]

You could use re.finditer to find the longest match, and then replace
it manually by hand (via string slicing).

(a match is the longest if (m.end() - m.start()) is the largest --
so, max(re.finditer(...), key=lambda m: (m.end() = m.start()))

-- Devin

P.S. does anyone else get bothered by how it's slice.start and
slice.stop, but match.start() and match.end() ?

On Fri, Dec 16, 2011 at 11:49 AM, John Gordon  wrote:
> According to the documentation on re.sub(), it replaces the leftmost
> matching pattern.
>
> However, I want to replace the *longest* matching pattern, which is
> not necessarily the leftmost match.  Any suggestions?
>
> I'm working with IPv6 CIDR strings, and I want to replace the longest
> match of "(:|$)+" with ":".  But when I use re.sub() it replaces
> the leftmost match, even if there is a longer match later in the string.
>
> I'm also looking for a regexp that will remove leading zeroes in each
> four-digit group, but will leave a single zero if the group was all
> zeroes.
>
> Thanks!
>
> --
> John Gordon                   A is for Amy, who fell down the stairs
> gor...@panix.com              B is for Basil, assaulted by bears
>                                -- Edward Gorey, "The Gashlycrumb Tinies"
>
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: re.sub(): replace longest match instead of leftmost match?

[MRAB]

On 16/12/2011 16:49, John Gordon wrote:

According to the documentation on re.sub(), it replaces the leftmost
matching pattern.

However, I want to replace the *longest* matching pattern, which is
not necessarily the leftmost match.  Any suggestions?

I'm working with IPv6 CIDR strings, and I want to replace the longest
match of "(:|$)+" with ":".  But when I use re.sub() it replaces
the leftmost match, even if there is a longer match later in the string.

I'm also looking for a regexp that will remove leading zeroes in each
four-digit group, but will leave a single zero if the group was all
zeroes.


How about this:

result = re.sub(r"\b0+(\d)\b", r"\1", string)
--
http://mail.python.org/mailman/listinfo/python-list

Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]

[rusi]

On Dec 16, 3:25 pm, Eelco  wrote:
> Pseudo-backwards compatibility with other
> languages, I couldnt not care less for.

Double negations n Goedelian situations have interesting implications
(tho here its triple)
-- 
http://mail.python.org/mailman/listinfo/python-list

Making the case for "typed" lists/iterators in python

[Nathan Rice]

I realize this has been discussed in the past, I hope that I am
presenting a slightly different take on the subject that will prove
interesting.  This is primarily motivated by my annoyance with using
comprehensions in certain circumstances.

Currently, if you want to perform successive transformations on the
elements of a list, a couple of options:

1. Successive comprehensions:

L2 = [X(e) for e in L1]
L3 = [Y(e) for e in L2]
L4 = [Z(e) for e in L3]
or
L2 = [e.X() for e in L1]

This gets the job done and gives you access to all the intermediate
values, but isn't very succinct, particularly if you are in the habit
of using informative identifiers.

2. One comprehension:

L2 = [Z(X(Y(e))) for e in L1]
or
L2 = [e.X().Y().Z() for e in L1]

This gets the job done, but doesn't give you access to all the
intermediate values, and tends to be pretty awful to read.

Having "typed" lists let you take preexisting string/int/etc methods
and expose them in a vectorized context and provides an easy way for
developers to support both vectors and scalars in a single function
(you could easily "fix" other people's functions dynamically to
support both).  Additionally, "typed" lists/iterators will allow
improved code analysis and optimization.  The PyPy people have already
stated that they are working on implementing different strategies for
lists composed of a single type, so clearly there is already community
movement in this direction.

Just compare the above examples to their type-aware counterparts:

L2 = X(L1)
L2 = L1.X()

L2 = Z(Y(X(L1)))
L2 = L1.X().Y().Z()

Also, this would provide a way to clean up stuff like:

"\n".join(l.capitalize() for l in my_string.split("\n"))

into:

my_string.split("\n").capitalize().join_this("\n")

Before anyone gets up in arms at the idea of statically typed python,
what I am suggesting here would be looser than that.  Basically, I
believe it would be a good idea in instances where it is known that a
list of single type is going to be returned, to return a list subclass
(for example, StringList, IntegerList, etc).  To avoid handcuffing
people with types, the standard list modification methods could be
hooked so that if an object of an incorrect type is placed in the
list, a warning is raised and the list converts to a generic object
list.  The only stumbling block is that you can't use __class__ to
convert from stack types to heap types in CPython.  My workaround for
this would be to have a factory that creates generic "List" classes,
modifying the bases to produce the correct behavior.  Then, converting
from a typed list to a generic object list would just be a matter of
removing a member from the bases for a class.  This of course
basically kills the ability to perform type specific list optimization
in CPython, but that isn't necessarily true for other implementations.
 The additional type information would be preserved for code analysis
in any case.  The case would be even simpler for generators and other
iterators, as you don't have to worry about mutation.

I'd like to hear people's thoughts on the subject.  Currently we are
throwing away useful information in many cases that could be used for
code analysis, optimization and simpler interfaces.  I believe that
"typed" lists that get "demoted" to normal lists with a warning on out
of type operations preserve this information while providing complete
backwards compatibility and freedom.

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

Re: re.sub(): replace longest match instead of leftmost match?

[Ian Kelly]

On Fri, Dec 16, 2011 at 10:36 AM, MRAB  wrote:
> On 16/12/2011 16:49, John Gordon wrote:
>>
>> According to the documentation on re.sub(), it replaces the leftmost
>> matching pattern.
>>
>> However, I want to replace the *longest* matching pattern, which is
>> not necessarily the leftmost match.  Any suggestions?
>>
>> I'm working with IPv6 CIDR strings, and I want to replace the longest
>> match of "(:|$)+" with ":".  But when I use re.sub() it replaces
>> the leftmost match, even if there is a longer match later in the string.
>>
>> I'm also looking for a regexp that will remove leading zeroes in each
>> four-digit group, but will leave a single zero if the group was all
>> zeroes.
>>
> How about this:
>
> result = re.sub(r"\b0+(\d)\b", r"\1", string)

Close.

pattern = r'\b0+([1-9a-f]+|0)\b'
re.sub(pattern, r'\1', string, flags=re.IGNORECASE)

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

Re: Python Interpreter Error with PyDev (Eclipse IDE)

[Fabio Zadrozny]

It seems you have a version of Python 2.5 in your system and when
starting up Python 3.2.2 it's getting things from 2.5 (this would
probably also happen on the command line).

The usual suspect is that you defined a PYTHONROOT variable which is
pointing to Python 2.5 and not to the python you're using...

Cheers,

Fabio

On Thu, Dec 15, 2011 at 10:20 PM, Joshua Jodrey  wrote:
> Hi,
> This is my first email to this list, so I apologize if there's a better
> mailing-list for this type of question.
>
> I'm looking to get started with python development, so I downloaded Python
> 3.2.2 and PyDev IDE for Eclipse.  When I go to configure my interpreter for
> a new python project, Windows gives me the following error:
>
> "python.exe has stopped working"
>
> and then Eclipse shows
>
> "Error getting info on interpreter
> "See error log for details.
> No output was in the standard output when trying to create the interpreter
> info.
> The error output contains:>>Fatal Python error: Py_Initialize: unable to
> load the file system codec
>   File "C:\csvn\Python25\\lib\encodings\__init__.py", line 120
>     raise CodecRegistryError,\
>                             ^
> SyntaxError: invalid syntax
>
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
> <<"
>
> Does anybody have any idea what this means or what I'm doing wrong?  I've
> tried re-installing Python, but still can't get it to work.
> And again, if I'm in the wrong place, please direct me to the proper
> mailing-list or forum.
>
> Thanks!
> Josh
>
> P.S. I'm not subscribed to this mailer, so please include me in your
> replies!
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: re.sub(): replace longest match instead of leftmost match?

[Ian Kelly]

On Fri, Dec 16, 2011 at 10:57 AM, Ian Kelly  wrote:
> On Fri, Dec 16, 2011 at 10:36 AM, MRAB  wrote:
>> On 16/12/2011 16:49, John Gordon wrote:
>>>
>>> According to the documentation on re.sub(), it replaces the leftmost
>>> matching pattern.
>>>
>>> However, I want to replace the *longest* matching pattern, which is
>>> not necessarily the leftmost match.  Any suggestions?
>>>
>>> I'm working with IPv6 CIDR strings, and I want to replace the longest
>>> match of "(:|$)+" with ":".  But when I use re.sub() it replaces
>>> the leftmost match, even if there is a longer match later in the string.
>>>
>>> I'm also looking for a regexp that will remove leading zeroes in each
>>> four-digit group, but will leave a single zero if the group was all
>>> zeroes.
>>>
>> How about this:
>>
>> result = re.sub(r"\b0+(\d)\b", r"\1", string)
>
> Close.
>
> pattern = r'\b0+([1-9a-f]+|0)\b'
> re.sub(pattern, r'\1', string, flags=re.IGNORECASE)

Doh, that's still not quite right.

pattern = r'\b0{1,3}([1-9a-f][0-9a-f]*|0)\b'
re.sub(pattern, r'\1', string, flags=re.IGNORECASE)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Making the case for "typed" lists/iterators in python

[Roy Smith]

In article ,
 Nathan Rice  wrote:

> I'd like to hear people's thoughts on the subject.  Currently we are
> throwing away useful information in many cases that could be used for
> code analysis, optimization and simpler interfaces. 

Most of this was TL:DNR, but I will admit I often wish for a better way 
to log intermediate values.  For example, a common pattern in the code 
I'm working with now is functions that end in:

   return [Foo(x) for x in bunch_of_x_thingies]

When something goes amiss and I want to debug the problem, I often 
transform that into:

temp = [Foo(x) for x in bunch_of_x_thingies]
logger.debug(temp)
return temp

It would be convenient to be able to get at and log the intermediate 
value without having to pull it out to an explicit temporary.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: re.sub(): replace longest match instead of leftmost match?

[MRAB]

On 16/12/2011 17:57, Ian Kelly wrote:

On Fri, Dec 16, 2011 at 10:36 AM, MRAB  wrote:

 On 16/12/2011 16:49, John Gordon wrote:


 According to the documentation on re.sub(), it replaces the leftmost
 matching pattern.

 However, I want to replace the *longest* matching pattern, which is
 not necessarily the leftmost match.  Any suggestions?

 I'm working with IPv6 CIDR strings, and I want to replace the longest
 match of "(:|$)+" with ":".  But when I use re.sub() it replaces
 the leftmost match, even if there is a longer match later in the string.

 I'm also looking for a regexp that will remove leading zeroes in each
 four-digit group, but will leave a single zero if the group was all
 zeroes.


 How about this:

 result = re.sub(r"\b0+(\d)\b", r"\1", string)


Close.

pattern = r'\b0+([1-9a-f]+|0)\b'
re.sub(pattern, r'\1', string, flags=re.IGNORECASE)


Ah, OK.

The OP said "digit" instead of "hex digit". That's my excuse. :-)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Making the case for "typed" lists/iterators in python

[Stefan Behnel]

Nathan Rice, 16.12.2011 18:48:

I realize this has been discussed in the past, I hope that I am
presenting a slightly different take on the subject that will prove
interesting.  This is primarily motivated by my annoyance with using
comprehensions in certain circumstances.

Currently, if you want to perform successive transformations on the
elements of a list, a couple of options:

1. Successive comprehensions:

L2 = [X(e) for e in L1]
L3 = [Y(e) for e in L2]
L4 = [Z(e) for e in L3]
or
L2 = [e.X() for e in L1]

This gets the job done and gives you access to all the intermediate
values, but isn't very succinct, particularly if you are in the habit
of using informative identifiers.

2. One comprehension:

L2 = [Z(X(Y(e))) for e in L1]
or
L2 = [e.X().Y().Z() for e in L1]

This gets the job done, but doesn't give you access to all the
intermediate values, and tends to be pretty awful to read.

Having "typed" lists let you take preexisting string/int/etc methods
and expose them in a vectorized context and provides an easy way for
developers to support both vectors and scalars in a single function
(you could easily "fix" other people's functions dynamically to
support both).  Additionally, "typed" lists/iterators will allow
improved code analysis and optimization.  The PyPy people have already
stated that they are working on implementing different strategies for
lists composed of a single type, so clearly there is already community
movement in this direction.

Just compare the above examples to their type-aware counterparts:

L2 = X(L1)
L2 = L1.X()

L2 = Z(Y(X(L1)))
L2 = L1.X().Y().Z()


What keeps you from implementing this? You don't need to change the 
language for it, just wrap the list in a class that overrides __getattr__() 
to return something that does the appropriate transformation for each 
element. I would be surprised if you needed more than a couple of lines of 
Python code for that.


Stefan

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

Re: Making the case for "typed" lists/iterators in python

[Chris Angelico]

On Sat, Dec 17, 2011 at 5:05 AM, Roy Smith  wrote:
> Most of this was TL:DNR, but I will admit I often wish for a better way
> to log intermediate values.  For example, a common pattern in the code
> I'm working with now is functions that end in:
>
>   return [Foo(x) for x in bunch_of_x_thingies]
>
> When something goes amiss and I want to debug the problem, I often
> transform that into:
>
>    temp = [Foo(x) for x in bunch_of_x_thingies]
>    logger.debug(temp)
>    return temp
>
> It would be convenient to be able to get at and log the intermediate
> value without having to pull it out to an explicit temporary.

tee = lambda func,arg: (func(arg),arg)[1]

return tee(logger.debug,[Foo(x) for x in bunch_of_x_thingies])

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

Re: Making the case for "typed" lists/iterators in python

[Arnaud Delobelle]

On 16 December 2011 18:25, Chris Angelico  wrote:

> tee = lambda func,arg: (func(arg),arg)[1]

What a strange way to spell it!

def tee(func, arg):
func(arg)
return arg

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

Re: re.sub(): replace longest match instead of leftmost match?

[Roy Smith]

In article ,
 John Gordon  wrote:

> I'm working with IPv6 CIDR strings, and I want to replace the longest
> match of "(:|$)+" with ":".  But when I use re.sub() it replaces
> the leftmost match, even if there is a longer match later in the string.
> 
> I'm also looking for a regexp that will remove leading zeroes in each
> four-digit group, but will leave a single zero if the group was all
> zeroes.

Having done quite a bit of IPv6 work, my opinion here is that you're 
trying to do The Wrong Thing.

What you want is an IPv6 class which represents an address in some 
canonical form.  It would have constructors which accept any of the 
RFC-2373 defined formats.  It would also have string formatting methods 
to convert the internal form into any of these formats.

Then, instead of attempting to regex your way directly from one string 
representation to another, you would do something like:

addr_string = "FEDC:BA98:7654:3210:FEDC:BA98:7654:321"
print IPv6(addr_string).to_short_form()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Making the case for "typed" lists/iterators in python

[Chris Angelico]

On Sat, Dec 17, 2011 at 5:38 AM, Arnaud Delobelle  wrote:
> On 16 December 2011 18:25, Chris Angelico  wrote:
>
>> tee = lambda func,arg: (func(arg),arg)[1]
>
> What a strange way to spell it!
>
> def tee(func, arg):
>    func(arg)
>    return arg

I started with that version and moved to the lambda for compactness.
But either way works.

It's no more strange than the way some people omit the u from colour. :)

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

Re: Making the case for "typed" lists/iterators in python

[Nathan Rice]

Nothing stops me from implementing it, in fact it is VERY trivial to
wrap member class methods onto a list subclass, and wrap functions to
support vectorized behavior.  The problem is that as soon as you hit
anything outside your code that returns a list or iterator, everything
gets blown away unless you explicitly wrap the return value, which
entirely defeats the point.

On Fri, Dec 16, 2011 at 1:23 PM, Stefan Behnel  wrote:
> Nathan Rice, 16.12.2011 18:48:
>
>> I realize this has been discussed in the past, I hope that I am
>> presenting a slightly different take on the subject that will prove
>> interesting.  This is primarily motivated by my annoyance with using
>> comprehensions in certain circumstances.
>>
>> Currently, if you want to perform successive transformations on the
>> elements of a list, a couple of options:
>>
>> 1. Successive comprehensions:
>>
>> L2 = [X(e) for e in L1]
>> L3 = [Y(e) for e in L2]
>> L4 = [Z(e) for e in L3]
>> or
>> L2 = [e.X() for e in L1]
>>
>> This gets the job done and gives you access to all the intermediate
>> values, but isn't very succinct, particularly if you are in the habit
>> of using informative identifiers.
>>
>> 2. One comprehension:
>>
>> L2 = [Z(X(Y(e))) for e in L1]
>> or
>> L2 = [e.X().Y().Z() for e in L1]
>>
>> This gets the job done, but doesn't give you access to all the
>> intermediate values, and tends to be pretty awful to read.
>>
>> Having "typed" lists let you take preexisting string/int/etc methods
>> and expose them in a vectorized context and provides an easy way for
>> developers to support both vectors and scalars in a single function
>> (you could easily "fix" other people's functions dynamically to
>> support both).  Additionally, "typed" lists/iterators will allow
>> improved code analysis and optimization.  The PyPy people have already
>> stated that they are working on implementing different strategies for
>> lists composed of a single type, so clearly there is already community
>> movement in this direction.
>>
>> Just compare the above examples to their type-aware counterparts:
>>
>> L2 = X(L1)
>> L2 = L1.X()
>>
>> L2 = Z(Y(X(L1)))
>> L2 = L1.X().Y().Z()
>
>
> What keeps you from implementing this? You don't need to change the language
> for it, just wrap the list in a class that overrides __getattr__() to return
> something that does the appropriate transformation for each element. I would
> be surprised if you needed more than a couple of lines of Python code for
> that.
>
> Stefan
>
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Making the case for "typed" lists/iterators in python

[Devin Jeanpierre]

> 2. One comprehension:
>
> L2 = [Z(X(Y(e))) for e in L1]
> or
> L2 = [e.X().Y().Z() for e in L1]

I want to say that maybe this is better done by functions like map()
(although, Python is missing a composition operator which might be
handy, and mapping method calls isn't pretty).

I don't know that it belongs as a method on lists, especially since
that means you can't do the same thing on, for example, generators.

Or I guess, the easy answer to that lattermost objection is to make it
typed iterators rather than typed lists.

-- Devin

On Fri, Dec 16, 2011 at 12:48 PM, Nathan Rice
 wrote:
> I realize this has been discussed in the past, I hope that I am
> presenting a slightly different take on the subject that will prove
> interesting.  This is primarily motivated by my annoyance with using
> comprehensions in certain circumstances.
>
> Currently, if you want to perform successive transformations on the
> elements of a list, a couple of options:
>
> 1. Successive comprehensions:
>
> L2 = [X(e) for e in L1]
> L3 = [Y(e) for e in L2]
> L4 = [Z(e) for e in L3]
> or
> L2 = [e.X() for e in L1]
>
> This gets the job done and gives you access to all the intermediate
> values, but isn't very succinct, particularly if you are in the habit
> of using informative identifiers.
>
> 2. One comprehension:
>
> L2 = [Z(X(Y(e))) for e in L1]
> or
> L2 = [e.X().Y().Z() for e in L1]
>
> This gets the job done, but doesn't give you access to all the
> intermediate values, and tends to be pretty awful to read.
>
> Having "typed" lists let you take preexisting string/int/etc methods
> and expose them in a vectorized context and provides an easy way for
> developers to support both vectors and scalars in a single function
> (you could easily "fix" other people's functions dynamically to
> support both).  Additionally, "typed" lists/iterators will allow
> improved code analysis and optimization.  The PyPy people have already
> stated that they are working on implementing different strategies for
> lists composed of a single type, so clearly there is already community
> movement in this direction.
>
> Just compare the above examples to their type-aware counterparts:
>
> L2 = X(L1)
> L2 = L1.X()
>
> L2 = Z(Y(X(L1)))
> L2 = L1.X().Y().Z()
>
> Also, this would provide a way to clean up stuff like:
>
> "\n".join(l.capitalize() for l in my_string.split("\n"))
>
> into:
>
> my_string.split("\n").capitalize().join_this("\n")
>
> Before anyone gets up in arms at the idea of statically typed python,
> what I am suggesting here would be looser than that.  Basically, I
> believe it would be a good idea in instances where it is known that a
> list of single type is going to be returned, to return a list subclass
> (for example, StringList, IntegerList, etc).  To avoid handcuffing
> people with types, the standard list modification methods could be
> hooked so that if an object of an incorrect type is placed in the
> list, a warning is raised and the list converts to a generic object
> list.  The only stumbling block is that you can't use __class__ to
> convert from stack types to heap types in CPython.  My workaround for
> this would be to have a factory that creates generic "List" classes,
> modifying the bases to produce the correct behavior.  Then, converting
> from a typed list to a generic object list would just be a matter of
> removing a member from the bases for a class.  This of course
> basically kills the ability to perform type specific list optimization
> in CPython, but that isn't necessarily true for other implementations.
>  The additional type information would be preserved for code analysis
> in any case.  The case would be even simpler for generators and other
> iterators, as you don't have to worry about mutation.
>
> I'd like to hear people's thoughts on the subject.  Currently we are
> throwing away useful information in many cases that could be used for
> code analysis, optimization and simpler interfaces.  I believe that
> "typed" lists that get "demoted" to normal lists with a warning on out
> of type operations preserve this information while providing complete
> backwards compatibility and freedom.
>
> Nathan
> --
> http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]

[Eelco]

On 16 dec, 18:38, rusi  wrote:
> On Dec 16, 3:25 pm, Eelco  wrote:
>
> > Pseudo-backwards compatibility with other
> > languages, I couldnt not care less for.
>
> Double negations n Goedelian situations have interesting implications
> (tho here its triple)

Heh. Well at least my extra (unintended) negation is semantically
consistent with the actual english usage of the phrase, which omits
the negation completely :). (I could care less)

But ill stick with trying to change one language at a time :).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Making the case for "typed" lists/iterators in python

[Mel Wilson]

Chris Angelico wrote:

> It's no more strange than the way some people omit the u from colour. :)

Bonum Petronio Arbiteri, bonum mihi.

Mel.

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

Re: Making the case for "typed" lists/iterators in python

[Stefan Behnel]

Nathan Rice, 16.12.2011 19:51:

Nothing stops me from implementing it, in fact it is VERY trivial to
wrap member class methods onto a list subclass, and wrap functions to
support vectorized behavior.  The problem is that as soon as you hit
anything outside your code that returns a list or iterator, everything
gets blown away unless you explicitly wrap the return value, which
entirely defeats the point.


The point you are trying to make, maybe.

Stefan

PS: note that you top-posted in your reply, you should try to avoid that.

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

Re: Making the case for "typed" lists/iterators in python

[Ben Finney]

Roy Smith  writes:

> When something goes amiss and I want to debug the problem, I often 
> transform that into:
>
> temp = [Foo(x) for x in bunch_of_x_thingies]
> logger.debug(temp)
> return temp
>
> It would be convenient to be able to get at and log the intermediate 
> value without having to pull it out to an explicit temporary.

What's wrong with that though?

You're not “pulling it out to” anything; you're binding a name to the
value in order to do several things with it. Exactly what you say you
want to do. It's explicit and clear.

-- 
 \  “What we usually pray to God is not that His will be done, but |
  `\   that He approve ours.” —Helga Bergold Gross |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Make a small function thread safe

[Tim Delaney]

On 17 December 2011 02:05, Brad Tilley  wrote:

> On Dec 16, 9:36 am, Tim Wintle  wrote:
>
> > should be:
> >   def run(t):
> >   with lock:
> >   shared_container.append(t.name)
> >
> > (or lock.acquire() and lock.release() as you mentioned)
>
>
> Thanks Tim. The with statement is closer to the C++ code (IMO) more so
> than the explicit acquire() and release() so I'll use that approach. I
> appreciate your advice.


Most definitely. The acquire/release code shown was erroneous, since it
would not release if an exception was thrown. The with code is effectively
equivalent to:

lock.acquire()

try:
...
finally:
lock.release()

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

Re: re.sub(): replace longest match instead of leftmost match?

[John Gordon]

In  Devin Jeanpierre 
 writes:

> You could use re.finditer to find the longest match, and then replace
> it manually by hand (via string slicing).

> (a match is the longest if (m.end() - m.start()) is the largest --
> so, max(re.finditer(...), key=3Dlambda m: (m.end() =3D m.start()))

I ended up doing something similar:

# find the longest match
longest_match = ''
for word in re.findall('((:?)+)', ip6):
if len(word[0]) > len(longest_match):
longest_match = word[0]

# if we found a match, replace it with a colon
if longest_match:
  ip6 = re.sub(longest_match, ':', ip6, 1)

Thanks!

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

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

Re: re.sub(): replace longest match instead of leftmost match?

[John Gordon]

In  Ian Kelly 
 writes:

> >>> I'm also looking for a regexp that will remove leading zeroes in each
> >>> four-digit group, but will leave a single zero if the group was all
> >>> zeroes.

> pattern = r'\b0{1,3}([1-9a-f][0-9a-f]*|0)\b'
> re.sub(pattern, r'\1', string, flags=re.IGNORECASE)

Perfect.  Thanks Ian!

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

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

Re: re.sub(): replace longest match instead of leftmost match?

[John Gordon]

In  Roy Smith  writes:

> Having done quite a bit of IPv6 work, my opinion here is that you're 
> trying to do The Wrong Thing.

> What you want is an IPv6 class which represents an address in some 
> canonical form.  It would have constructors which accept any of the 
> RFC-2373 defined formats.  It would also have string formatting methods 
> to convert the internal form into any of these formats.

> Then, instead of attempting to regex your way directly from one string 
> representation to another, you would do something like:

> addr_string = "FEDC:BA98:7654:3210:FEDC:BA98:7654:321"
> print IPv6(addr_string).to_short_form()

This does sound like a more robust solution.  I'll give it some thought.
Thanks Roy!

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

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

Re: re.sub(): replace longest match instead of leftmost match?

[MRAB]

On 16/12/2011 21:04, John Gordon wrote:

In  Devin 
Jeanpierre  writes:


 You could use re.finditer to find the longest match, and then replace
 it manually by hand (via string slicing).



 (a match is the longest if (m.end() - m.start()) is the largest --
 so, max(re.finditer(...), key=3Dlambda m: (m.end() =3D m.start()))


I ended up doing something similar:

 # find the longest match
 longest_match = ''
 for word in re.findall('((:?)+)', ip6):
 if len(word[0])>  len(longest_match):
 longest_match = word[0]

 # if we found a match, replace it with a colon
 if longest_match:
   ip6 = re.sub(longest_match, ':', ip6, 1)


For a simple replace, using re is probably overkill. The .replace
method is a better solution:

ip6 = longest_match.replace(ip6, ':', 1)
--
http://mail.python.org/mailman/listinfo/python-list

Re: AttributeError in "with" statement (3.2.2)

[Terry Reedy]

On 12/16/2011 4:22 AM, Steven D'Aprano wrote:

On Thu, 15 Dec 2011 19:39:17 -0500, Terry Reedy wrote:
[...]

After reading your post, I think I have worked out where our disagreement
lines: you think that bound methods and instance methods are not the same
thing,


Do you agree that an unbound method and a bound method are different? In 
Python, as indicated by the glossary entry, an unspecified 'method' is 
usually meant to be an unbound method. It is am important distinction 
and I do not see why you insist on confusing the two.



and that a function defined inside a class is different from a
function outside of a class.


That, and your repetition of the same claim further on, is a insulting lie.

Def statements always create functions. I have known that for 14 years 
since the first day I started with Python. I have never thought 
differently. If you actually think that I have, you are wrong.


What I have said from my first response is that a function that is an 
attribute of a class, *whether defined in or outside the class*, gets 
special treatment when accessed via an instance of the class. And that 
is the truth.


If you are ever interested in learning anything from me on this subject, 
re=read what I already wrote with a more open mind than you have so far. 
Otherwise, I am done.


--
Terry Jan Reedy

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

Re: Make a small function thread safe

[Lie Ryan]

On 12/17/2011 01:30 AM, Brad Tilley wrote:

Or perhaps run should look like this instead:

 def run(t):
 lock.acquire()
 shared_container.append(t.name )
 lock.release()

That seems a bit barbaric to me, not sure.


change that to:

def run(t):
with lock:
shared_container.append(t.name )


the `with-statement` will call lock.acquire() and lock.release().

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

Re: Making the case for "typed" lists/iterators in python

[Terry Reedy]

On 12/16/2011 1:05 PM, Roy Smith wrote:


I'm working with now is functions that end in:

return [Foo(x) for x in bunch_of_x_thingies]

When something goes amiss and I want to debug the problem, I often
transform that into:

 temp = [Foo(x) for x in bunch_of_x_thingies]
 logger.debug(temp)
 return temp

It would be convenient to be able to get at and log the intermediate
value without having to pull it out to an explicit temporary.


Decorate the function with @logreturn and you do not have to touch the 
function code. If the logging module does not now have such a decorator 
predefined (I simply do not know), perhaps it should.


--
Terry Jan Reedy

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

Re: re.sub(): replace longest match instead of leftmost match?

[Terry Reedy]

On 12/16/2011 1:36 PM, Roy Smith wrote:


What you want is an IPv6 class which represents an address in some
canonical form.  It would have constructors which accept any of the
RFC-2373 defined formats.  It would also have string formatting methods
to convert the internal form into any of these formats.

Then, instead of attempting to regex your way directly from one string
representation to another, you would do something like:

addr_string = "FEDC:BA98:7654:3210:FEDC:BA98:7654:321"
print IPv6(addr_string).to_short_form()


There are at least 2 third-party IP classes in use. I would not be 
surprised if at least one of them does this.


--
Terry Jan Reedy

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

Re: Python Interpreter Error with PyDev (Eclipse IDE)

[Joshua Jodrey]

Thanks Fabio!

I looked at my environment variables, and the only one python related was 
PYTHONHOME, and that was set to C:\csvn\Python25.  So I changed that to 
C:\Python32\ and I added an environment variable for PYTHONROOT and set that to 
the same value.  It now seems to work!
I must have had a some python directories laying around from an odd svn 
installation or something...

Thanks again!



 From: Fabio Zadrozny 
To: Joshua Jodrey  
Cc: "python-list@python.org"  
Sent: Friday, December 16, 2011 12:57 PM
Subject: Re: Python Interpreter Error with PyDev (Eclipse IDE)
 
It seems you have a version of Python 2.5 in your system and when
starting up Python 3.2.2 it's getting things from 2.5 (this would
probably also happen on the command line).

The usual suspect is that you defined a PYTHONROOT variable which is
pointing to Python 2.5 and not to the python you're using...

Cheers,

Fabio

On Thu, Dec 15, 2011 at 10:20 PM, Joshua Jodrey  wrote:
> Hi,
> This is my first email to this list, so I apologize if there's a better
> mailing-list for this type of question.
>
> I'm looking to get started with python development, so I downloaded Python
> 3.2.2 and PyDev IDE for Eclipse.  When I go to configure my interpreter for
> a new python project, Windows gives me the following error:
>
> "python.exe has stopped working"
>
> and then Eclipse shows
>
> "Error getting info on interpreter
> "See error log for details.
> No output was in the standard output when trying to create the interpreter
> info.
> The error output contains:>>Fatal Python error: Py_Initialize: unable to
> load the file system codec
>   File "C:\csvn\Python25\\lib\encodings\__init__.py", line 120
>     raise CodecRegistryError,\
>                             ^
> SyntaxError: invalid syntax
>
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
> <<"
>
> Does anybody have any idea what this means or what I'm doing wrong?  I've
> tried re-installing Python, but still can't get it to work.
> And again, if I'm in the wrong place, please direct me to the proper
> mailing-list or forum.
>
> Thanks!
> Josh
>
> P.S. I'm not subscribed to this mailer, so please include me in your
> replies!
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>-- 
http://mail.python.org/mailman/listinfo/python-list

Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]

[Gregory Ewing]

Eelco wrote:

the actual english usage of the phrase, which omits
the negation completely :). (I could care less)


No, that's the American usage. The English usage is
"I couldn't care less", which has the advantage of
actually making sense.

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

Re: AttributeError in "with" statement (3.2.2)

[Ethan Furman]

Terry Reedy wrote:

On 12/16/2011 4:22 AM, Steven D'Aprano wrote:

On Thu, 15 Dec 2011 19:39:17 -0500, Terry Reedy wrote:
[...]

After reading your post, I think I have worked out where our disagreement
lies: you think that bound methods and instance methods are not the same
thing,


Do you agree that an unbound method and a bound method are different? In 
Python, as indicated by the glossary entry, an unspecified 'method' is 
usually meant to be an unbound method. 


I think you two are in violent agreement as far as how Python is 
functioning, and the conflict is in the names given to the various 
pieces... I think a glossary would help (please correct me):


function:  callable code suite

method:  function that lives in a class

unbound method:  function that lives in a class

bound method:  callable wrapper around function that has been extracted 
from class that will supply the instance object to the function (note: 
Python does not save these, they are recreated at each lookup)



and here is where I think you two diverge:

instance method (Steven):  a bound method that has been saved into the 
instance __dict__ (no matter how created)


instance method (Terry):  a function that must be looked up in the class


Have I missed anything?

Honestly-trying-learn-the-distinctions-ly yours,

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

Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]

[Eelco]

On Dec 17, 12:49 am, Gregory Ewing 
wrote:
> Eelco wrote:
> > the actual english usage of the phrase, which omits
> > the negation completely :). (I could care less)
>
> No, that's the American usage. The English usage is
> "I couldn't care less", which has the advantage of
> actually making sense.
>
> --
> Greg

Oh thanks for clearing that up, never noticed a division along these
lines.

And yes, I agree; 'I couldnt care less' makes much more sense. 'I
could care less' can only make sense if you interpret it
sarcastically, as if omitting an 'oh wait, I cant', but that does not
seem congruent with how its typically pronounced. Just another case of
suboptimal language design; but where can you submit EEP's?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]

[Roy Smith]

In article 
<2420abd7-7d91-4bc9-bb3b-d8ec1680e...@u32g2000yqe.googlegroups.com>,
 Eelco  wrote:

> And yes, I agree; 'I couldnt care less' makes much more sense. 'I
> could care less' can only make sense if you interpret it
> sarcastically, as if omitting an 'oh wait, I cant', but that does not
> seem congruent with how its typically pronounced. 

"I care so little about the subject that I am unwilling to spend one of 
my precious apostrophes to properly express the sentiment"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: AttributeError in "with" statement (3.2.2)

[Ethan Furman]

Ethan Furman wrote:

Terry Reedy wrote:

On 12/16/2011 4:22 AM, Steven D'Aprano wrote:

On Thu, 15 Dec 2011 19:39:17 -0500, Terry Reedy wrote:
[...]

After reading your post, I think I have worked out where our 
disagreement

lies: you think that bound methods and instance methods are not the same
thing,


Do you agree that an unbound method and a bound method are different? 
In Python, as indicated by the glossary entry, an unspecified 'method' 
is usually meant to be an unbound method. 


I think you two are in violent agreement as far as how Python is 
functioning, and the conflict is in the names given to the various 
pieces... I think a glossary would help (please correct me):


function:  callable code suite

method:  function that lives in a class

unbound method:  function that lives in a class

bound method:  callable wrapper around function that has been extracted 
from class that will supply the instance object to the function (note: 
Python does not save these, they are recreated at each lookup)


I think the above 'bound method' definition should be attributed to 
Terry, and Steven's follows:


bound method:  callable wrapper around any function that will accept an 
instance object as the first parameter, and the wrapper will supply said 
instance object when calling the function (and where/how function was 
created is irrelevent, as is where the wrapper is stored)



and here is where I think you two diverge:

instance method (Steven):  a bound method that has been saved into the 
instance __dict__ (no matter how created)


instance method (Terry):  a function that must be looked up in the class


Have I missed anything?

Honestly-trying-learn-the-distinctions-ly yours,

~Ethan~


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

Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]

[Steven D'Aprano]

On Fri, 16 Dec 2011 11:40:11 -0800, Eelco wrote:

> On 16 dec, 18:38, rusi  wrote:
>> On Dec 16, 3:25 pm, Eelco  wrote:
>>
>> > Pseudo-backwards compatibility with other languages, I couldnt not
>> > care less for.
>>
>> Double negations n Goedelian situations have interesting implications
>> (tho here its triple)
> 
> Heh. Well at least my extra (unintended) negation is semantically
> consistent with the actual english usage of the phrase, which omits the
> negation completely :). (I could care less)

Oh please. "I could care less" is not English. That's American.

Here in Australia, we follow the English practice of saying that we 
couldn't care less.


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

Re: AttributeError in "with" statement (3.2.2)

[Steven D'Aprano]

On Fri, 16 Dec 2011 17:05:57 -0500, Terry Reedy wrote:

> On 12/16/2011 4:22 AM, Steven D'Aprano wrote:
>> On Thu, 15 Dec 2011 19:39:17 -0500, Terry Reedy wrote: [...]
>>
>> After reading your post, I think I have worked out where our
>> disagreement lines: you think that bound methods and instance methods
>> are not the same thing,
> 
> Do you agree that an unbound method and a bound method are different? 

"Are different" or "are different types"?

Bound and unbound methods in Python 2 are the same type. They are 
different in the sense that one is effectively a curry of the other, but 
they are implemented as a single type. So presumably the difference is a 
bound method has a slot filled and an unbound method doesn't, or some 
other implementation detail.

In Python 3, unbound methods don't exist.


> In
> Python, as indicated by the glossary entry, an unspecified 'method' is
> usually meant to be an unbound method. 

I think you are badly confused here. The glossary talks about calling 
methods as an attribute of an instance, e.g. instance.method(), and the 
method receiving the instance as the first argument. That's a bound 
method, not unbound. How do you conclude that this indicates that an 
unspecified "method" is unbound?

Your conclusion is especially nonsensical because unbound methods don't 
exist in Python 3 -- you're alleging that the usual meaning of "method" 
is something which no longer exists in the language!

method
A function which is defined inside a class body. If called as 
an attribute of an instance of that class, the method will get
the instance object as its first argument (which is usually
called self). See function and nested scope.

http://docs.python.org/glossary.html


> It is am important distinction
> and I do not see why you insist on confusing the two.

It is not an important distinction, and I am not confusing the two. Bound 
or unbound, it is still an instance method.


>> and that a function defined inside a class is different from a function
>> outside of a class.
> 
> That, and your repetition of the same claim further on, is a insulting
> lie.

If you can't assume I'm carrying on this discussion in good faith, then  
we have a serious problem. This is not like you Terry -- I've been 
reading your posts for many years, and you're not usually so obstreperous.


> Def statements always create functions. I have known that for 14 years
> since the first day I started with Python. I have never thought
> differently. If you actually think that I have, you are wrong.

I'm glad to hear it. But nevertheless you have made statements (which I 
quoted, and you deleted from your reply) that suggest the opposite. If I 
have misinterpreted them, or if you had worded them badly, there's no 
need to attribute malice to me. Calling me a liar for something said in 
good faith and which I prefixed with "I think" is simply not cool.



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

Re: % is not an operator [was Re: Verbose and flexible args and kwargs syntax]

[David Robinow]

On Fri, Dec 16, 2011 at 7:54 PM, Steven D'Aprano
 wrote:
> On Fri, 16 Dec 2011 11:40:11 -0800, Eelco wrote:
>
>> On 16 dec, 18:38, rusi  wrote:
>>> On Dec 16, 3:25 pm, Eelco  wrote:
>>>
>>> > Pseudo-backwards compatibility with other languages, I couldnt not
>>> > care less for.
>>>
>>> Double negations n Goedelian situations have interesting implications
>>> (tho here its triple)
>>
>> Heh. Well at least my extra (unintended) negation is semantically
>> consistent with the actual english usage of the phrase, which omits the
>> negation completely :). (I could care less)
>
> Oh please. "I could care less" is not English. That's American.
>
> Here in Australia, we follow the English practice of saying that we
> couldn't care less.
Well the phrase is still somewhat controversial in the US. I never
heard it until age 19 (in 1966) and have always been somewhat
disdainful of those using it. But it appears to be hopeless.
 http://articles.boston.com/2010-10-24/lifestyle/29303907_1_care-peeves-decades
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Make a small function thread safe

[John Nagle]

On 12/16/2011 2:08 PM, Lie Ryan wrote:

On 12/17/2011 01:30 AM, Brad Tilley wrote:

Or perhaps run should look like this instead:

def run(t):
lock.acquire()
shared_container.append(t.name )
lock.release()

That seems a bit barbaric to me, not sure.


change that to:

def run(t):
with lock:
shared_container.append(t.name )


the `with-statement` will call lock.acquire() and lock.release().



   And, importantly, if you leave the "with" via an exception, the
lock will be unlocked.

John Nagle

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

root[:]=[root,root]

[YAN HUA]

Hi,all. Could anybody tell how this code works?
>>> root = [None, None]
>>> root[:] = [root, root]
>>> root
[[...], [...]]
>>> root[0]
[[...], [...]]
>>> root[0][0][1][1][0][0][0][1][1]
[[...], [...]]
>>>

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

Re: AttributeError in "with" statement (3.2.2)

[Steven D'Aprano]

On Fri, 16 Dec 2011 15:26:30 -0800, Ethan Furman wrote:

> Terry Reedy wrote:
>> On 12/16/2011 4:22 AM, Steven D'Aprano wrote:
[...]

> I think you two are in violent agreement as far as how Python is
> functioning, and the conflict is in the names given to the various
> pieces... I think a glossary would help (please correct me):
> 
> function:  callable code suite

Sure, why not?

Informally: a function is some object which can be called and returns a 
result. Hence we sometimes call str() and int() functions even though 
they are actually implemented as types. "Callable" would be better for 
such informal use, but newbies may not recognise the term.

To be more precise: a function is a particular type of callable object 
created by the def and lambda statements.


> method:  function that lives in a class

Informally, I'm happy with that definition, and use it myself. Under 99% 
of circumstances, it would be overly pedantic to describe spam in the 
following as anything other than a method:

class C:
def spam(self): pass

Call it the duck-type principle: since spam quacks like a duck, we might 
as well call it a duck. If you only care about the easy cases, then spam 
is a method and we're done.

But as a formal definition, it fails on two fronts: functions that live 
inside classes are not actually methods, they are functions, and while 
methods are commonly found in classes, they can also be found in 
instances, or anywhere else for that matter.


Functions inside classes are still functions


I said that since spam quacks like a method, we might as well call it a 
method. But it doesn't swim like a method: it's actually still a function 
with a remarkable power of mimicry.

There are places and times where the fact that spam is not actually a 
method comes through. The three most important examples in my opinion are:

  * inside the class suite, during class definition time, if you use
or inspect spam, you will see it is a function and not a method;

  * if you bypass the getattr mechanism for looking up attributes, e.g.
use C.__dict__['spam'] instead of C().spam, you will see that spam
is stored in the dict as a function object, not a method object;

  * (Python 3 only) if use the standard getattr mechanism, but call it 
on the class instead of an instance, you will get the function 
object instead of a method.

So, to be precise: spam is actually a function. It is stored as a 
function inside C.__dict__, but when you retrieve it using C().spam 
Python automagically builds a method object wrapping spam and gives you 
that instead. This distinction is important, well, hardly ever, but on 
the rare occasion it is important, you need to know it.

One example of when it may be important: because methods are created as 
needed, you can't assume that identity checks will necessarily pass for 
methods: `inst.spam is inst.spam` may not be true.


Methods can be created outside of classes
-

The normal way to get a method is by defining it inside a class. In Java, 
I believe that is the *only* way to get methods, but this is Python, and 
we have other options. Methods are first class objects, which means they 
have a type and a constructor, so if you can get hold of their type, you 
can make them by hand.

You can retrieve the method type two ways:

  * call type on a method you made the usual way: type(C().spam);

  * or import types and use types.MethodType.

Confusingly, the method type calls itself  but is 
exported via the types module as MethodType. Oh well.

MethodType requires two arguments, In Python 2, it accepts an optional 
third argument. Since Python 2 is the past, I'll only talk about the 
Python 3 version, where the signature might look something like this:

MethodType(callable, instance) => instancemethod object

This creates a wrapper around callable (usually, but not necessarily a 
function) and binds instance to that wrapper so the first argument 
(conventionally called self) can be automatically provided.

Another way to create methods is by calling the function object __get__ 
method by hand. That's what gets used in the normal C().spam case.

So you can create methods without putting them inside a class. One trick 
is that you can customise behaviour on a per-instance basis by overriding 
the normal method living inside the class with one which lives inside the 
instance:

class C:
def spam(self):
return "Spam spam spam, lovely SPAM!!!"

c = C()
c.spam = types.MethodType(lambda self: "Bloody vikings!", c)

Instance c now has a custom method which overrides C.spam.

[Aside #1: I think this was the original point of contention between 
Terry and I. For reasons I still don't understand, it seems to me that he 
denies that the per-instance method spam is actually a method, since it 
doesn't live inside the class.]

[Aside #2: this per-instance method trick may not work for

Re: root[:]=[root,root]

[Lie Ryan]

On 12/17/2011 01:40 PM, YAN HUA wrote:

Hi,all. Could anybody tell how this code works?
 >>> root = [None, None]


First, you're creating a list of two None, let's say it's list-1. Then 
you bind the name 'root' to list-1.



 >>> root[:] = [root, root]


Next, you assign list-1's first member with list-1 and list-1's second 
member with list-1.



 >>> root
[[...], [...]]


The result is a recursive list, both list-1's first and second  member 
is list-1 itself.



 >>> root[0]
[[...], [...]]
 >>> root[0][0][1][1][0][0][0][1][1]
[[...], [...]]
 >>>

Thanks.





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