Johannes Bauer dfnsonfsdu...@gmx.de wrote in message
news:min9t3$e56$1...@news.albasani.net...
On 10.05.2015 10:58, Frank Millman wrote:
It is then a simple extra step to say -
EMPTY_L:IST = ()
and if required -
EMPTY_DICT = ()
and expand the explanation to show why a tuple is
Johannes Bauer dfnsonfsdu...@gmx.de wrote in message
news:min3f0$2gh$1...@news.albasani.net...
On 08.05.2015 14:04, Dave Angel wrote:
It might be appropriate to define the list at top-level, as
EMPTY_LIST=[]
and in your default argument as
def x(y, z=EMPTY_LIST):
and with
On 08.05.2015 14:04, Dave Angel wrote:
It might be appropriate to define the list at top-level, as
EMPTY_LIST=[]
and in your default argument as
def x(y, z=EMPTY_LIST):
and with the all-caps, you're thereby promising that nobody will modify
that list.
(I'd tend to do the None
On 10.05.2015 10:58, Frank Millman wrote:
It is then a simple extra step to say -
EMPTY_L:IST = ()
and if required -
EMPTY_DICT = ()
and expand the explanation to show why a tuple is used instead.
So if there was a situation where the overhead of testing for None became a
Gregory Ewing greg.ew...@canterbury.ac.nz wrote in message
news:cr5sc6fgfm...@mid.individual.net...
Frank Millman wrote:
The absolutely clearest way to write it would
probably be
def f(things = None):
things is a mapping of stuff to be operated on
if things:
for
Frank Millman wrote:
There are two operations I might perform on the dictionary -
1. iterate over the keys and retrieve the values
2: use 'in' to test if a given string exists as a key
Both of these operations will work on a tuple and give the desired result,
so it is a very valid
Frank Millman fr...@chagford.com wrote in message
news:mik7j6$59n$1...@ger.gmane.org...
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote in message
news:554cd119$0$12977$c3e8da3$54964...@news.astraweb.com...
On Fri, 8 May 2015 08:53 pm, Frank Millman wrote:
Does z have to be a
Hi all
I have often read about the gotcha regarding 'mutable default arguments'
that frequently trips people up.
I use them from time to time, but I have never had a problem. I have just
delved a bit deeper to see if I am skating on thin ice.
AFAICT my usage is safe. If I use a list as an
On Fri, May 8, 2015 at 6:01 PM, Frank Millman fr...@chagford.com wrote:
I have often read about the gotcha regarding 'mutable default arguments'
that frequently trips people up.
I use them from time to time, but I have never had a problem. I have just
delved a bit deeper to see if I am
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote in message
news:554c8b0a$0$12992$c3e8da3$54964...@news.astraweb.com...
On Fri, 8 May 2015 06:01 pm, Frank Millman wrote:
Hi all
[...]
However, every time I look at my own code, and I see def x(y, z=[]):
. it looks wrong
On Fri, 8 May 2015 06:01 pm, Frank Millman wrote:
Hi all
I have often read about the gotcha regarding 'mutable default arguments'
that frequently trips people up.
I use them from time to time, but I have never had a problem. I have just
delved a bit deeper to see if I am skating on thin
On Fri, 8 May 2015 08:53 pm, Frank Millman wrote:
Does z have to be a list? Could you use an empty tuple instead?
def x(y, z=()): ...
That was Chris' suggestion as well (thanks Chris).
The idea appealed to me, but then I found a situation where I pass in a
dictionary instead of a list,
Dave Angel da...@davea.name wrote in message
news:554ca652.1000...@davea.name...
On 05/08/2015 06:53 AM, Frank Millman wrote:
It might be appropriate to define the list at top-level, as
EMPTY_LIST=[]
and in your default argument as
def x(y, z=EMPTY_LIST):
and with the all-caps,
Ben Finney ben+pyt...@benfinney.id.au wrote in message
news:85y4kzb90f@benfinney.id.au...
Frank Millman fr...@chagford.com writes:
If I use a list as an argument, I only use it to pass values *into*
the function, but I never modify the list.
You've had good reasons why a mutable
On 05/08/2015 06:53 AM, Frank Millman wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote in message
news:554c8b0a$0$12992$c3e8da3$54964...@news.astraweb.com...
On Fri, 8 May 2015 06:01 pm, Frank Millman wrote:
Hi all
[...]
However, every time I look at my own code, and I
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote in message
news:554cd119$0$12977$c3e8da3$54964...@news.astraweb.com...
On Fri, 8 May 2015 08:53 pm, Frank Millman wrote:
Does z have to be a list? Could you use an empty tuple instead?
def x(y, z=()): ...
That was Chris'
Frank Millman fr...@chagford.com writes:
If I use a list as an argument, I only use it to pass values *into*
the function, but I never modify the list.
You've had good reasons why a mutable default argument is a good idea.
I'll address another aspect of the question: passing a structured
two underscores before the name of a variable within
a class declaration but in the many examples of code I looked at this is
not widely used. I also read that encapsulation is unpythonic.
Questions:
2) If it is in fact true that encapsulation is rarely used
On Sat, 31 Aug 2013 12:46:52 +0100, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
# THIS DOES NOT HAPPEN IN PYTHON
# or any other language, as far as I am aware
x = 23
y = x # y now has the value 23
x = 42 # change the value of the object ### NOT SO! ###
print y
= prints 42
On Sat, 31 Aug 2013 05:57:47 -0700, Fabrice Pombet wrote:
Steve, I think that your definition of encapsulation is too wide to give
a reasonable answer to the question at hand.
My definition of encapsulation is based on the plain language definition.
It is also common in computer programming
On Sun, Sep 1, 2013 at 6:10 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Java and C++ allow you to declare members as public, so it is *not true*
that calling methods is the only way to change members. If you accept
Steve Holden's (wrong) definition above, Java and C++ don't
That said, though, when you consider the language ecosystem rather
than just the language, there is a strong tendency for Java and C++
code to wrap everything up with functions (no public data members),
whereas Python code is far more likely to have external code directly
access data
On 09/01/2013 03:09 AM, Fabrice Pombet wrote:
So I guess that we are actually all agreeing on this one.
No, we are not.
encapsulation != inaccessible except by getters/setters
--
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
In article mailman.455.1378062400.19984.python-l...@python.org,
Ethan Furman et...@stoneleaf.us wrote:
On 09/01/2013 03:09 AM, Fabrice Pombet wrote:
So I guess that we are actually all agreeing on this one.
No, we are not.
encapsulation != inaccessible except by getters/setters
@value.setter
def value(self, new_value)
validate(new_value)
self._value = new_value
class PlainPython:
value = None
In the Javaesque class we see the unPythonic way of using getters/setters; in the ProtectedPython* class we see the
pythonic way of providing getters/setters
On 2 September 2013 06:33, Ethan Furman et...@stoneleaf.us wrote:
class PlainPython:
value = None
In the Javaesque class we see the unPythonic way of using getters/setters;
in the ProtectedPython* class we see the pythonic way of providing
getters/setters**; in the PlainPython class
In article mailman.461.1378072496.19984.python-l...@python.org,
Tim Delaney timothy.c.dela...@gmail.com wrote:
On 2 September 2013 06:33, Ethan Furman et...@stoneleaf.us wrote:
class PlainPython:
value = None
In the Javaesque class we see the unPythonic way of using getters
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
[…] programmers have been using the *principle* of encapsulation since
before Grace Hopper was an admiral.
[…]
Encapsulation and information hiding are distinct things -- you can
have one without the other.
[…]
One of the most
On 09/01/2013 02:54 PM, Tim Delaney wrote:
Roy Smith wrote:
Nothing is accessible in Python except via getters and setters. The
only difference between Python and, say, C++ in this regard is that the
Python compiler writes them for you most of the time and doesn't make
you put ()'s at the end
In article mailman.464.1378078348.19984.python-l...@python.org,
Ben Finney ben+pyt...@benfinney.id.au wrote:
One of the more annoying traits of humanity is that whatever context we
first encounter a term is disproportionately privileged, causing us to
irrationally dismiss better (more useful,
In article mailman.468.1378083075.19984.python-l...@python.org,
Ethan Furman et...@stoneleaf.us wrote:
On 09/01/2013 02:54 PM, Tim Delaney wrote:
Roy Smith wrote:
Nothing is accessible in Python except via getters and setters. The
only difference between Python and, say, C++ in this
On Sun, 01 Sep 2013 15:13:06 -0400, Roy Smith wrote:
In article mailman.455.1378062400.19984.python-l...@python.org,
Ethan Furman et...@stoneleaf.us wrote:
On 09/01/2013 03:09 AM, Fabrice Pombet wrote:
So I guess that we are actually all agreeing on this one.
No, we are not.
On Sun, 01 Sep 2013 20:59:25 -0400, Roy Smith wrote:
In article mailman.468.1378083075.19984.python-l...@python.org,
Ethan Furman et...@stoneleaf.us wrote:
On 09/01/2013 02:54 PM, Tim Delaney wrote:
Roy Smith wrote:
Nothing is accessible in Python except via getters and setters. The
On 09/01/2013 05:59 PM, Roy Smith wrote:
Ethan Furman wrote:
On 09/01/2013 02:54 PM, Tim Delaney wrote:
Roy Smith wrote:
Nothing is accessible in Python except via getters and setters. The
only difference between Python and, say, C++ in this regard is that the
Python compiler writes them
On Saturday, August 31, 2013 4:35:39 AM UTC+2, Steven D'Aprano wrote:
On Fri, 30 Aug 2013 10:43:28 -0700, Fabrice Pombet wrote:
On Saturday, August 17, 2013 2:26:32 PM UTC+2, Fernando Saldanha wrote:
2) If it is in fact true that encapsulation is rarely used, how do I
deal
On 08/31/2013 08:07 AM, Fabrice Pombet wrote:
well, look at that:
a=(1,2)
a=2+3 -a is an object and I have changed its type and value from outside.
No, `a` is not an object, so you did not change the type of any object.
`a` is just a name (a label), that initially refers to the tuple (1,
On 08/30/2013 11:07 PM, Fabrice Pombet wrote:
... long discussion elided ...
well, look at that:
a=(1,2)
a=2+3 -a is an object and I have changed its type and value from outside. As
far as I am concerned this is one hell of an encapsulation violation... Could you
do this -strictly speaking-
On Saturday, August 31, 2013 9:03:58 AM UTC+2, Gary Herron wrote:
On 08/30/2013 11:07 PM, Fabrice Pombet
wrote:
... long discussion elided ...
well, look at that:
a=(1,2)
a=2+3 -a is an object and I have changed its type and value from outside. As
far as I am
On Saturday, August 31, 2013 9:42:55 AM UTC+2, Fabrice Pombet wrote:
On Saturday, August 31, 2013 9:03:58 AM UTC+2, Gary Herron wrote:
On 08/30/2013 11:07 PM, Fabrice Pombet
wrote:
... long discussion elided ...
well, look at that:
On Fri, 30 Aug 2013 23:07:47 -0700, Fabrice Pombet wrote:
well, look at that:
a=(1,2)
a=2+3 -a is an object and I have changed its type and value from
outside.
Incorrect. You have not changed the type or value of any object. a is
not an object, it is a *name*, and while you can change
On 8/31/13 7:46 AM, Steven D'Aprano wrote:
On Fri, 30 Aug 2013 23:07:47 -0700, Fabrice Pombet wrote:
well, look at that:
a=(1,2)
a=2+3 -a is an object and I have changed its type and value from
outside.
Incorrect. You have not changed the type or value of any object. a is
not an object, it
http://nedbatchelder.com/text/names.html
--Ned.
This is an excellent explanation, thank you. It is mostly of theoretical
interest though, and in practice, I still contend that the consequences towards
the syntax are (or seem, if you prefer) analogous to those of the lack of
On Saturday, August 31, 2013 1:46:52 PM UTC+2, Steven D'Aprano wrote:
On Fri, 30 Aug 2013 23:07:47 -0700, Fabrice Pombet wrote:
well, look at that:
a=(1,2)
a=2+3 -a is an object and I have changed its type and value from
outside.
Incorrect. You have not changed
On 1 September 2013 03:31, Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
On Fri, 30 Aug 2013 23:07:47 -0700 (PDT), Fabrice Pombet fp2...@gmail.com
declaimed the following:
well, look at that:
a=(1,2)
a=2+3 -a is an object and I have changed its type and value from
outside. As far as I
declaration but in the many examples of code I looked at this is not widely
used. I also read that encapsulation is unpythonic.
Questions:
2) If it is in fact true that encapsulation is rarely used, how do I deal
with the fact that other programmers can easily alter the values
On Fri, 30 Aug 2013 10:43:28 -0700, Fabrice Pombet wrote:
On Saturday, August 17, 2013 2:26:32 PM UTC+2, Fernando Saldanha wrote:
2) If it is in fact true that encapsulation is rarely used, how do I
deal with the fact that other programmers can easily alter the values
of members of my
declaration but in the many examples of code I looked at this is not widely
used. I also read that encapsulation is unpythonic.
Questions:
1) Is there a good text where I can read about the language philosophy? What
practices are pythonic or unpythonic?
2) If it is in fact
On Mon, Aug 19, 2013, at 3:05, Steven D'Aprano wrote:
In this toy example, both parties are at fault: the author of Parrot for
unnecessary data-hiding of something which is so obviously a useful piece
of information and should be part of the public interface,
It may wish to be notified when
On Aug 21, 2013 10:53 AM, random...@fastmail.us wrote:
On Mon, Aug 19, 2013, at 3:05, Steven D'Aprano wrote:
In this toy example, both parties are at fault: the author of Parrot for
unnecessary data-hiding of something which is so obviously a useful
piece
of information and should be part
On Wed, 21 Aug 2013 12:52:06 -0400, random832 wrote:
On Mon, Aug 19, 2013, at 3:05, Steven D'Aprano wrote:
In this toy example, both parties are at fault: the author of Parrot
for unnecessary data-hiding of something which is so obviously a useful
piece of information and should be part of
On Sun, 18 Aug 2013 18:15:10 +0100, Joshua Landau wrote:
On 17 August 2013 17:17, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Sat, 17 Aug 2013 05:26:32 -0700, fsaldan1 wrote:
how do I
deal with the fact that other programmers can easily alter the values
of members of my
On 17 August 2013 17:17, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Sat, 17 Aug 2013 05:26:32 -0700, fsaldan1 wrote:
how do I
deal with the fact that other programmers can easily alter the values of
members of my classes?
...
If they insist on messing with your private
. I also read that encapsulation is unpythonic.
Questions:
1) Is there a good text where I can read about the language philosophy? What
practices are pythonic or unpythonic?
2) If it is in fact true that encapsulation is rarely used, how do I deal with
the fact that other programmers can easily
In Guido's own words: We're all consenting adults here.
http://importthis.tumblr.com/post/6719643315/public-private-attributes
Skip
--
http://mail.python.org/mailman/listinfo/python-list
On 17 August 2013 22:26, fsald...@gmail.com wrote:
1) Is there a good text where I can read about the language philosophy? What
practices are pythonic or unpythonic?
2) If it is in fact true that encapsulation is rarely used, how do I deal
with the fact that other programmers can easily
On Sat, Aug 17, 2013 at 1:26 PM, fsald...@gmail.com wrote:
2) If it is in fact true that encapsulation is rarely used, how do I deal
with the fact that other programmers can easily alter the values of members
of my classes?
Very simply: You accept it. Let them! It's their responsibility.
that encapsulation is unpythonic.
That's *data hiding*, not encapsulation.
Very few languages -- possibly none at all -- can hide data from a
sufficiently motivated programmer. Python doesn't even try. We're all
adults here is the philosophy, and data hiding is by convention, not
enforced
examples of code I looked at this is not widely used. I also read that encapsulation
is unpythonic.
Questions:
1) Is there a good text where I can read about the language philosophy? What practices are
pythonic or unpythonic?
2) If it is in fact true that encapsulation is rarely used, how do I deal
On 8/17/2013 11:50 AM, Chris Angelico wrote:
On Sat, Aug 17, 2013 at 1:26 PM, fsald...@gmail.com wrote:
2) If it is in fact true that encapsulation is rarely used, how do I deal with
the fact that other programmers can easily alter the values of members of my
classes?
Very simply: You
On Sat, Aug 17, 2013 at 10:22 PM, Terry Reedy tjre...@udel.edu wrote:
On 8/17/2013 11:50 AM, Chris Angelico wrote:
On Sat, Aug 17, 2013 at 1:26 PM, fsald...@gmail.com wrote:
2) If it is in fact true that encapsulation is rarely used, how do I deal
with the fact that other programmers can
On Monday 20 April 2009 11:29:19 am J Kenneth King wrote:
Changing the ID value would break things on the server, so I
wanted to write the interface class to respect those conventions.
Then, take this opportunity fix the server and prevent it from breaking once
you change the ID, because:
Luis Zarrabeitia ky...@uh.cu writes:
On Monday 20 April 2009 11:29:19 am J Kenneth King wrote:
Changing the ID value would break things on the server, so I
wanted to write the interface class to respect those conventions.
Then, take this opportunity fix the server and prevent it from
On Wednesday 22 April 2009 01:44:38 pm J Kenneth King wrote:
Then, take this opportunity fix the server and prevent it from breaking
once you change the ID, because:
Unfortunately it's not my server to fix. I can suggest a patch, but
that's it.
Yes, that's unfortunate.
Btw, when I re-read
Luis Zarrabeitia ky...@uh.cu writes:
On Wednesday 22 April 2009 01:44:38 pm J Kenneth King wrote:
Then, take this opportunity fix the server and prevent it from breaking
once you change the ID, because:
Unfortunately it's not my server to fix. I can suggest a patch, but
that's it.
Yes,
self.foo = foo
@property
def id(self):
return self._id
...
I was recently informed that it was 'unpythonic' and have since been a
little confused by the term. I've heard it bandied about before but
never paid much attention. What is 'unpythonic'? What about
On Apr 17, 7:21 pm, J Kenneth King ja...@agentultra.com wrote:
Consider:
code:
class MyInterface(object):
def __get_id(self):
return self.__id
id = property(fget=__get_id)
def __init__(self,
or generators. I'd
like a more concrete explanation from someone who has encountered a
scenario where it was required.
I was recently informed that it was 'unpythonic' and have since been a
little confused by the term. I've heard it bandied about before but
never paid much attention. What is 'unpythonic
version stores its data in a name-mangled
attribute (two underscores), but you can also use a name-mangled
attribute for the MyInterface2 version if you want.
Neither version is foolproof.
I was recently informed that it was 'unpythonic' and have since been a
little confused by the term. I've
__init__(self, id, foo):
self.__id = id
self.foo = foo
class MyInterface2(object):
def __init__(self, id, foo):
self._id = id
self.foo = foo
@property
def id(self):
return self._id
...
I was recently informed that it was 'unpythonic' and have
id(self):
return self._id
...
I was recently informed that it was 'unpythonic' and have since been a
little confused by the term. I've heard it bandied about before but
never paid much attention. What is 'unpythonic'? What about this example
is unpythonic?
There are different
Assume having this class hierarchy: (in principle and without details)
class A(object):
class B1(A):
class B2(A):
class C1(A1):
class C2(A1):
class C3(B1):
class C4(B2):
each of those classes have an initializer __init__(self, data): and an
overloaded __new__(cls,
factory - and could work around using such a
mechanism. However I am interested to know if I could let the classes do the
work by themselves.
Yes, it can be done. Yes, it is unclear (and hence UnPythonic).
The class factory _is_ the straightforward way to do this. The
following
Em Dom, 2006-03-19 às 08:54 -0800, Scott David Daniels escreveu:
class A(object):
def __new__(class_, *args, **kwargs):
if class_ is A:
if want_a_B1(*args, **kwargs):
return B1(*args, **kwargs)
elif
be done. Yes, it is unclear (and hence UnPythonic).
The class factory _is_ the straightforward way to do this. The
following is the workaround (if you have to maintain A(...)):
class A(object):
def __new__(class_, *args, **kwargs):
if class_
Felipe Almeida Lessa wrote:
Em Dom, 2006-03-19 às 08:54 -0800, Scott David Daniels escreveu:
class A(object):
def __new__(class_, *args, **kwargs):
if class_ is A:
if want_a_B1(*args, **kwargs):
return B1(*args, **kwargs)
BrJohan wrote:
I know how to use a class factory - and could work around using such a
mechanism. However I am interested to know if I could let the classes do the
work by themselves.
You can, but a class factory is going to be much clearer and probably
more maintainable. From the user's
Erik Max Francis [EMAIL PROTECTED] writes:
You can, but a class factory is going to be much clearer and probably
more maintainable. From the user's perspective, there's no difference
from calling a class A to instantiate it, and calling a factory
function called A that selects the appropriate
Paul Rubin wrote:
I remember having a similar problem involving multiple base classes
and deciding that factory functions couldn't do quite what I wanted.
Here's a thread about it, with a recipe using metaclasses by Roeland
Rengelink:
http://tinyurl.com/rz6ne
Unfortunately, the
On Thu, 29 Sep 2005, Peter Corbett wrote:
One of my friends has recently taken up Python, and was griping a bit
about the language (it's too prescriptive for his tastes). In
particular, he didn't like the way that Python expressions were a bit
crippled. So I delved a bit into the language,
One of my friends has recently taken up Python, and was griping a bit
about the language (it's too prescriptive for his tastes). In
particular, he didn't like the way that Python expressions were a bit
crippled. So I delved a bit into the language, and found some sources
of syntactic sugar that I
[Peter]
http://www.pick.ucam.org/~ptc24/yvfc.html
Beautiful! Greenspun's Tenth Rule[1] performed before your very eyes! (Not
quite, because you started with Python so you were already half way there.
And yours probably isn't buggy. 8-)
[1] http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule
Peter Corbett [EMAIL PROTECTED] writes:
http://www.pick.ucam.org/~ptc24/yvfc.html
Madness! I love it.
--
http://mail.python.org/mailman/listinfo/python-list
Peter Corbett wrote:
One of my friends has recently taken up Python, and was griping a bit
about the language (it's too prescriptive for his tastes). In
particular, he didn't like the way that Python expressions were a bit
crippled. So I delved a bit into the language, and found some sources
[Peter]
http://www.pick.ucam.org/~ptc24/yvfc.html
[Jeff]
Yuma Valley Agricultural Center?
Yaak Valley Forest Council?
I went through the same process. My guess is Yes, Very F'ing Clever.
Peter?
--
Richie Hindle
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Richie Hindle [EMAIL PROTECTED] writes:
[Peter]
http://www.pick.ucam.org/~ptc24/yvfc.html
[Jeff]
Yuma Valley Agricultural Center?
Yaak Valley Forest Council?
I went through the same process. My guess is Yes, Very F'ing Clever.
Peter?
You're all thinking about it the wrong way (he
On Thursday 29 September 2005 04:53, Peter Corbett wrote:
One of my friends has recently taken up Python, and was griping a bit
about the language (it's too prescriptive for his tastes). In
particular, he didn't like the way that Python expressions were a bit
crippled. So I delved a bit into
Richie Hindle a écrit :
[Peter]
http://www.pick.ucam.org/~ptc24/yvfc.html
[Jeff]
Yuma Valley Agricultural Center?
Yaak Valley Forest Council?
I went through the same process. My guess is Yes, Very F'ing Clever.
Peter?
print ''.join(map(lambda x: chrord(x) - ord('a')) + 13)
fraca7 wrote:
Richie Hindle a écrit :
[Peter]
http://www.pick.ucam.org/~ptc24/yvfc.html
[Jeff]
Yuma Valley Agricultural Center?
Yaak Valley Forest Council?
I went through the same process. My guess is Yes, Very F'ing Clever.
Peter?
print ''.join(map(lambda x: chrord(x) -
Crypthonic could be the exact word...On 29 Sep 2005 15:19:11 +0100, Peter Corbett [EMAIL PROTECTED]
wrote:Richie Hindle [EMAIL PROTECTED]
writes: [Peter] http://www.pick.ucam.org/~ptc24/yvfc.html [Jeff] Yuma Valley Agricultural Center?
Yaak Valley Forest Council? I went through the same
fraca7 wrote:
Richie Hindle a écrit :
[Peter]
http://www.pick.ucam.org/~ptc24/yvfc.html
[Jeff]
Yuma Valley Agricultural Center?
Yaak Valley Forest Council?
I went through the same process. My guess is Yes, Very F'ing Clever.
Peter?
print ''.join(map(lambda x: chrord(x) -
fraca7 wrote:
print ''.join(map(lambda x: chrord(x) - ord('a')) + 13) % 26) +
ord('a')), 'yvfc'))
that's spelled
print yvfc.decode(rot-13)
or, if you prefer,
print yvfc.encode(rot-13)
, in contemporary python.
/F
--
http://mail.python.org/mailman/listinfo/python-list
On 9/29/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
fraca7 wrote:
print ''.join(map(lambda x: chrord(x) - ord('a')) + 13) % 26) +
ord('a')), 'yvfc'))
that's spelled
print yvfc.decode(rot-13)
or, if you prefer,
print yvfc.encode(rot-13)
, in contemporary python.
I'm not
I had always been negative on the boldeness of python on insisting that
unbound methods should have been applied only to its im_class instances.
Anyway this time I mixed in rightly, so I post this for comments.
## looking for a discovery .Start #
class _Mixin(object):
def
93 matches
Mail list logo
