Julio Di Egidio writes:
> On Friday, 29 April 2022 at 09:50:08 UTC+2, Loris Bennett wrote:
>> Hi,
>>
>> If I do
>>
>> import re
>> pattern =
>> re.compile(r'(?P\d*)(-?)(?P\d\d):(?P\d\d):(?P\d\d)')
>> s = '104-02:47:06'
>> match = pattern.search(s)
>> match_dict = match.groupdict('0')
>>
"Loris Bennett" writes:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>
>> "Loris Bennett" writes:
>>>I thought that 'days' would default to '0'.
>>
>> It will get the value '0' if (?P\d*) does
>> /not/ participate in the match.
>>
>> In your case, it /does/ participate in the match,
>>
r...@zedat.fu-berlin.de (Stefan Ram) writes:
> "Loris Bennett" writes:
>>I thought that 'days' would default to '0'.
>
> It will get the value '0' if (?P\d*) does
> /not/ participate in the match.
>
> In your case, it /does/ participate in the match,
> \d* matching the empty string.
>
>
Hi,
If I do
import re
pattern =
re.compile(r'(?P\d*)(-?)(?P\d\d):(?P\d\d):(?P\d\d)')
s = '104-02:47:06'
match = pattern.search(s)
match_dict = match.groupdict('0')
I get
match_dict
{'days': '104', 'hours': '02', 'minutes': '47', 'seconds': '06'}
However, if the string has no in
"D'Arcy J.M. Cain" :
> On Fri, 07 Oct 2016 16:09:19 +0200
> jmp wrote:
>> What about
>>
>> def test():
>>if not hasattr(test, '_store'): test._store={'x':0}
>>test._store['x'] += 1
>
> Why is everyone working so hard to avoid creating a class?
Hear, hear!
Marko
--
https://mail.python
quot; a écrit dans le message de
news:mailman.209.1475841371.30834.python-l...@python.org...
On 10/07/2016 01:38 PM, Daiyue Weng wrote:
So the rule of thumb for default argument value is "No mutable"
Cheers,
It can be used to store some variables from one call of
a function t
On Fri, 07 Oct 2016 16:09:19 +0200
jmp wrote:
> What about
>
> def test():
>if not hasattr(test, '_store'): test._store={'x':0}
>test._store['x'] += 1
Why is everyone working so hard to avoid creating a class?
--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da.
016 01:38 PM, Daiyue Weng wrote:
So the rule of thumb for default argument value is "No mutable"
Cheers,
It can be used to store some variables from one call of
a function to an other one.
def test( _store={'x':0}):
x = _store['x']
. do some stu
So the rule of thumb for default argument value is "No mutable"
Cheers,
It can be used to store some variables from one call of
a function to an other one.
def test( _store={'x':0}):
x = _store['x']
. do some stuff
_store['x'] = x
Fo
*is* a standard idiom.
> That is if you care about anyone reading your code ;)
Here's another example of a mutable default argument:
https://www.python.org/doc/essays/graphs/
Although it isn't actually being mutated. Nevertheless, if it is good enough
for Guido, then it should be
On Fri, 7 Oct 2016 10:38 pm, Daiyue Weng wrote:
> Hi, I declare two parameters for a function with default values [],
>
> def one_function(arg, arg1=[], arg2=[]):
>
> PyCharm warns me:
>
> Default argument value is mutable,
>
> what does it mean? and how to fix i
On 10/07/2016 02:07 PM, ast wrote:
"jmp" a écrit dans le message de
news:mailman.209.1475841371.30834.python-l...@python.org...
On 10/07/2016 01:38 PM, Daiyue Weng wrote:
So the rule of thumb for default argument value is "No mutable"
Cheers,
It can be used to
"jmp" a écrit dans le message de
news:mailman.209.1475841371.30834.python-l...@python.org...
On 10/07/2016 01:38 PM, Daiyue Weng wrote:
So the rule of thumb for default argument value is "No mutable"
Cheers,
It can be used to store some variables from one call
"Daiyue Weng" a écrit dans le message de
news:mailman.208.1475840291.30834.python-l...@python.org...
Hi, I declare two parameters for a function with default values [],
def one_function(arg, arg1=[], arg2=[]):
PyCharm warns me:
Default argument value is mutable,
what does it mea
On 10/07/2016 01:38 PM, Daiyue Weng wrote:
Hi, I declare two parameters for a function with default values [],
def one_function(arg, arg1=[], arg2=[]):
PyCharm warns me:
Default argument value is mutable,
what does it mean? and how to fix it?
cheers
You'll run into this bug
def
Hi, I declare two parameters for a function with default values [],
def one_function(arg, arg1=[], arg2=[]):
PyCharm warns me:
Default argument value is mutable,
what does it mean? and how to fix it?
cheers
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, Mar 12, 2014 at 8:09 AM, Piyush Verma <114piy...@gmail.com> wrote:
> Hi,
>
> I am using Thread class to create threads.
>
> thread = threading.Thread(target=Fun, args=[arg1, arg2, arg3="val"])
> thread.start()
>
>
> This code is throwing compilation error(Ipython).
> In [19]: import threa
- Original Message -
> Hi,
> I am using Thread class to create threads.
>
> thread = threading.Thread(target=Fun, args=[arg1, arg2, arg3="val"])
> thread.start()
>
> This code is throwing compilation error(Ipython).
> In [19]: import threading
> In [20]: def Fun(agr1, arg2, arg3=No
Hi,
I am using Thread class to create threads.
thread = threading.Thread(target=Fun, args=[arg1, arg2, arg3="val"])
thread.start()
This code is throwing compilation error(Ipython).
In [19]: import threading
In [20]: def Fun(agr1, arg2, arg3=None):
: pass
:
In [21]: thread =
On Tuesday, January 21, 2014 9:46:16 PM UTC+2, Chris Angelico wrote:
> On Wed, Jan 22, 2014 at 6:36 AM, Mû wrote:
> > These were clear and quick answers to my problem. I did not think of this
> > possibility: the default argument is created once, but accessible only by
> > th
On Wed, Jan 22, 2014 at 6:36 AM, Mû wrote:
> These were clear and quick answers to my problem. I did not think of this
> possibility: the default argument is created once, but accessible only by
> the function, therefore is not a global variable, whereas it looks like if
> it were at
indeed, I thought that
[2,3] was the default argument of the function f, thus I expected the three
calls of f() to be exactly equivalent.
In a sense, there is. The default for the argument is simply an object
like any other, and it's stored in one place.
For cases where you want a mutable
On Wed, Jan 22, 2014 at 6:11 AM, Mû wrote:
> The function acts as if there were a global variable x, but the call of x
> results in an error (undefined variable). I don't understand why the
> successive calls of f() don't return the same value: indeed, I thought that
>
in an error (undefined variable). I don't understand why the
successive calls of f() don't return the same value: indeed, I thought
that [2,3] was the default argument of the function f, thus I expected
the three calls of f() to be exactly equivalent.
I'm don't know much about
; The results are [2, 3, 1], [2, 3, 1, 1] and [2, 3, 1, 1, 1].
>
> The function acts as if there were a global variable x, but the call of
> x results in an error (undefined variable). I don't understand why the
> successive calls of f() don't return the same value: indeed,
the call of
x results in an error (undefined variable). I don't understand why the
successive calls of f() don't return the same value: indeed, I thought
that [2,3] was the default argument of the function f, thus I expected
the three calls of f() to be exactly equivalent.
I'm
On Mon, 12 Nov 2012 00:31:53 +, Oscar Benjamin wrote:
[...]
>>> You were right the first time, Chris. A point that happens to coincide
>>> with the arbitrarily chosen origin is no more truthy or falsey than
>>> any other. A vector of length 0 on the other hand is a very different
>>> beast.
>>
On 12 November 2012 01:29, Mark Lawrence wrote:
> On 12/11/2012 01:18, Oscar Benjamin wrote:
>>
>> On 12 November 2012 01:10, Mark Lawrence wrote:
>>>
>>> On 12/11/2012 00:31, Oscar Benjamin wrote:
Plain wrong. Vectors are not defined *from any origin*.
>>>
>>> So when the Captain says
In article ,
Oscar Benjamin wrote:
> But then I'm assuming you meant that 245 degrees was a bearing
> relative to North. Was it supposed to be relative to my current angle?
> Truthfully I wouldn't know what to do without asking the captain a
> couple more questions.
Granted, this requires some
On 12/11/2012 01:15, Roy Smith wrote:
In article ,
Mark Lawrence wrote:
On 12/11/2012 00:31, Oscar Benjamin wrote:
Plain wrong. Vectors are not defined *from any origin*.
So when the Captain says "full speed ahead, steer 245 degrees", you
haven't the faintest idea where you're going, be
On 12/11/2012 01:18, Oscar Benjamin wrote:
On 12 November 2012 01:10, Mark Lawrence wrote:
On 12/11/2012 00:31, Oscar Benjamin wrote:
Plain wrong. Vectors are not defined *from any origin*.
So when the Captain says "full speed ahead, steer 245 degrees", you haven't
the faintest idea where
In article ,
Mark Lawrence wrote:
> On 12/11/2012 00:31, Oscar Benjamin wrote:
> >
> > Plain wrong. Vectors are not defined *from any origin*.
> >
>
> So when the Captain says "full speed ahead, steer 245 degrees", you
> haven't the faintest idea where you're going, because you have no origin?
On 12 November 2012 01:10, Mark Lawrence wrote:
> On 12/11/2012 00:31, Oscar Benjamin wrote:
>>
>>
>> Plain wrong. Vectors are not defined *from any origin*.
>>
>
> So when the Captain says "full speed ahead, steer 245 degrees", you haven't
> the faintest idea where you're going, because you have
On 12/11/2012 00:31, Oscar Benjamin wrote:
Plain wrong. Vectors are not defined *from any origin*.
So when the Captain says "full speed ahead, steer 245 degrees", you
haven't the faintest idea where you're going, because you have no origin?
--
Cheers.
Mark Lawrence.
--
http://mail.python
On Nov 11, 4:31 pm, Oscar Benjamin wrote:
> On 11 November 2012 22:31, Steven D'Aprano
> > Nonsense. The length and direction of a vector is relative to the origin.
> > If the origin is arbitrary, as you claim, then so is the length of the
> > vector.
>
> Wrong on all counts. Neither the length n
On Nov 10, 11:33 am, Jennie wrote:
> What is the best solution to solve the following problem in Python 3.3?
>
> import math
> >>> class Point:
> ... def __init__(self, x=0, y=0):
> ... self.x = x
> ... self.y = y
> ... def __sub__(self, other):
> ... return Point(
On 11 November 2012 22:31, Steven D'Aprano
wrote:
> On Sun, 11 Nov 2012 14:21:19 +, Oscar Benjamin wrote:
>
>> On 11 November 2012 02:47, Chris Angelico wrote:
>>> On Sun, Nov 11, 2012 at 1:43 PM, Ian Kelly
>>> wrote:
On Sat, Nov 10, 2012 at 7:13 PM, Chris Angelico
wrote:
> I
On Sun, 11 Nov 2012 14:21:19 +, Oscar Benjamin wrote:
> On 11 November 2012 02:47, Chris Angelico wrote:
>> On Sun, Nov 11, 2012 at 1:43 PM, Ian Kelly
>> wrote:
>>> On Sat, Nov 10, 2012 at 7:13 PM, Chris Angelico
>>> wrote:
I would not assume that. The origin is a point, just like any
On 11 November 2012 02:47, Chris Angelico wrote:
> On Sun, Nov 11, 2012 at 1:43 PM, Ian Kelly wrote:
>> On Sat, Nov 10, 2012 at 7:13 PM, Chris Angelico wrote:
>>> I would not assume that. The origin is a point, just like any other.
>>> With a Line class, you could deem a zero-length line to be l
On Sat, Nov 10, 2012 at 11:43 PM, Ian Kelly wrote:
> Where I wrote "(0,0) is the origin" above I was not referring to a
> point, not a tuple, but I can see how that was confusing.
What I meant to say is I *was* referring to a point. Gah!
--
http://mail.python.org/mailman/listinfo/python-list
On Sat, Nov 10, 2012 at 7:53 PM, Roy Smith wrote:
> In article ,
> Ian Kelly wrote:
>
>> On Sat, Nov 10, 2012 at 7:13 PM, Chris Angelico wrote:
>> > I would not assume that. The origin is a point, just like any other.
>> > With a Line class, you could deem a zero-length line to be like a
>> > z
In article ,
Ian Kelly wrote:
> On Sat, Nov 10, 2012 at 7:13 PM, Chris Angelico wrote:
> > I would not assume that. The origin is a point, just like any other.
> > With a Line class, you could deem a zero-length line to be like a
> > zero-element list, but Point(0,0) is more like the tuple (0,0
On Sun, Nov 11, 2012 at 1:43 PM, Ian Kelly wrote:
> On Sat, Nov 10, 2012 at 7:13 PM, Chris Angelico wrote:
>> I would not assume that. The origin is a point, just like any other.
>> With a Line class, you could deem a zero-length line to be like a
>> zero-element list, but Point(0,0) is more like
On Sat, Nov 10, 2012 at 7:13 PM, Chris Angelico wrote:
> I would not assume that. The origin is a point, just like any other.
> With a Line class, you could deem a zero-length line to be like a
> zero-element list, but Point(0,0) is more like the tuple (0,0) which
> is definitely True.
It's more
On Sun, Nov 11, 2012 at 12:13 PM, Steven D'Aprano
wrote:
> Almost but not quite. I assume that, in a full Point class, you would
> want Point(0, 0) to count as false in a boolean context. (A "falsey"
> value, like None, [], 0.0, etc.)
I would not assume that. The origin is a point, just like any
On 10 November 2012 19:33, Jennie wrote:
> What is the best solution to solve the following problem in Python 3.3?
>
> import math
class Point:
> ... def __init__(self, x=0, y=0):
> ... self.x = x
> ... self.y = y
> ... def __sub__(self, other):
> ... return Po
On Sat, 10 Nov 2012 20:33:05 +0100, Jennie wrote:
[...]
> I propose three solutions. The first one:
>
> >>> class Point:
> ... def __init__(self, x=0, y=0):
> ... self.x = x
> ... self.y = y
> ... def __sub__(self, other):
> ... return Point(self.x - other.x, self
On 11/10/2012 03:51 PM, Jennie wrote:
> On 11/10/2012 09:29 PM, Terry Reedy wrote:
>
>> On 11/10/2012 2:33 PM, Jennie wrote:
>>>
>>> I propose three solutions. The first one:
>>>
>>> >>> class Point:
>>> ... def __init__(self, x=0, y=0):
>>> ... self.x = x
>>> ... self.y = y
>>
On 11/10/2012 09:29 PM, Terry Reedy wrote:
On 11/10/2012 2:33 PM, Jennie wrote:
I propose three solutions. The first one:
>>> class Point:
... def __init__(self, x=0, y=0):
... self.x = x
... self.y = y
... def __sub__(self, other):
... return Point(self.x - o
On 11/10/2012 2:33 PM, Jennie wrote:
What is the best solution to solve the following problem in Python 3.3?
import math
>>> class Point:
... def __init__(self, x=0, y=0):
... self.x = x
... self.y = y
... def __sub__(self, other):
... return Point(self.x - other
On Sun, Nov 11, 2012 at 6:33 AM, Jennie wrote:
> ... def distance(self, point=None):
> ... p = point if point else Point()
I'd go with this one. Definitely not the third one, which mutates the
class according to a current global every time a Point is instantiated
- could be *extremely
What is the best solution to solve the following problem in Python 3.3?
import math
>>> class Point:
... def __init__(self, x=0, y=0):
... self.x = x
... self.y = y
... def __sub__(self, other):
... return Point(self.x - other.x, self.y - other.y)
... def dista
I agree with you Steven that the OP should avoid __getattribute__ and
the like for many a thing. I also agree with your last statement. I
try to answer the OP's question without much "You shouldn't do this's
and don't do that's". I trust them to make thier own decisions. I'd
say "A much better solu
On Thu, 30 Dec 2010 11:26:50 -0800, DevPlayer wrote:
> There's some_object.some_method.func_defaults
Not quite -- method objects don't expose the function attributes
directly. You need some_object.some_method.im_func to get the function
object, which then has a func_defaults attribute.
> and
There's some_object.some_method.func_defaults and
some_function.func_defaults both are a settable attribute. How to set
the methods func_defaults? You'd have to have code in
_getattribute__(yourmethod) if not __getattr__(yourmethod)
def __getattribute__(self, attr):
if attr == self.my_method:
On Thursday 16 December 2010, 00:56:31 Steven D'Aprano wrote:
> On Wed, 15 Dec 2010 21:10:05 +0100, Hans-Peter Jansen wrote:
> > Since this is a major pitfall, it might be worth mentioning, that
> > mutable default arguments are generally a bad idea, as the default
> > arguments are evaluated just
On Wed, 15 Dec 2010 21:10:05 +0100, Hans-Peter Jansen wrote:
> Since this is a major pitfall, it might be worth mentioning, that
> mutable default arguments are generally a bad idea, as the default
> arguments are evaluated just once, hence e.g. using an empty list might
> contain the items, that
On Monday 13 December 2010, 18:14:27 Godson Gera wrote:
> On Sun, Dec 12, 2010 at 5:05 PM, ernest wrote:
> > Hi,
> >
> > I'd like to have a reference to an instance attribute as
> > default argument in a method. It doesn't work because
> > "self&quo
On 12/13/2010 12:14 PM, Godson Gera wrote:
>
>
> On Sun, Dec 12, 2010 at 5:05 PM, ernest <mailto:nfdi...@gmail.com>> wrote:
>
> Hi,
>
> I'd like to have a reference to an instance attribute as
> default argument in a method. It doesn't
On Sun, Dec 12, 2010 at 5:05 PM, ernest wrote:
> Hi,
>
> I'd like to have a reference to an instance attribute as
> default argument in a method. It doesn't work because
> "self" is not defined at the time the method signature is
> evaluated. For example:
ernest wrote:
Hi,
I'd like to have a reference to an instance attribute as
default argument in a method. It doesn't work because
"self" is not defined at the time the method signature is
evaluated. For example:
class C(object):
def __init__(self):
self.foo = 5
On Sun, Dec 12, 2010 at 3:35 AM, ernest wrote:
> Hi,
>
> I'd like to have a reference to an instance attribute as
> default argument in a method. It doesn't work because
> "self" is not defined at the time the method signature is
> evaluated. For example:
Hi,
I'd like to have a reference to an instance attribute as
default argument in a method. It doesn't work because
"self" is not defined at the time the method signature is
evaluated. For example:
class C(object):
def __init__(self):
self.foo = 5
def
On 5/11/2010 3:41 PM, Back9 wrote:
self._value will be instance variable
Then set it in the __init__ method. Read the tutorial and ref manual on
Python class statements, which are a bit different from what you might
be used to.
--
http://mail.python.org/mailman/listinfo/python-list
meant
class test:
self._value =0
def func(self, pos =elf._value)
You're still defining the class, so how could there possibly be an
instance of it to refer to as "self" yet (outside of a method body)?
Also, just so you know, default argument values are only evaluated
once, at t
Back9 wrote:
Hi,
Is this grammer working in Python?
class test:
self._value = 10
def func(self, self._value)
When i try it, it complains about undefined self.
i don't know why.
TIA
... not exactly; try:
class Test:
_value = 10
def func(self):
print id(self._value), self._v
>> i don't know why.
>>
>> >> TIA
>>
>> > Sorry
>> > here is the what i meant
>> > class test:
>> > self._value = 10
>> > def func(self, pos = self._value)
>>
>> You're still defining the class, so h
t; > here is the what i meant
> > class test:
> > self._value = 10
> > def func(self, pos = self._value)
>
> You're still defining the class, so how could there possibly be an
> instance of it to refer to as "self" yet (outside of a method body)?
>
10
> def func(self, pos = self._value)
You're still defining the class, so how could there possibly be an
instance of it to refer to as "self" yet (outside of a method body)?
Also, just so you know, default argument values are only evaluated
once, at the time the function/method is d
On May 11, 3:06 pm, Back9 wrote:
> Hi,
>
> Is this grammer working in Python?
>
> class test:
> self._value = 10
> def func(self, self._value)
>
> When i try it, it complains about undefined self.
>
> i don't know why.
>
> TIA
Sorry
here is the what i meant
class test:
self._value = 10
de
Hi,
Is this grammer working in Python?
class test:
self._value = 10
def func(self, self._value)
When i try it, it complains about undefined self.
i don't know why.
TIA
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, Oct 29, 2008 at 12:44 PM, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
> Chris Rebert a écrit :
> (snip)
>
>> Note that the "accumulation" behavior of lists is considered an
>> aberration
>>
>
> By who ?
>
All the python newbies who don't read the tutorial and get tripped up by
this.
Chris Rebert a écrit :
(snip)
Note that the "accumulation" behavior of lists is considered an
aberration
By who ?
--
http://mail.python.org/mailman/listinfo/python-list
Paulo J. Matos a écrit :
Hi all,
Going through the tutorial brought up a question. Consider the functions:
def f(a, L=[]):
L.append(a)
return L
print f(3)
print f(9)
print f(7)
def f1(i = 0):
i = i + 1
print i
f1()
f1()
f1()
f1()
Since the f accumulates the values in L, I wa
On Wed, Oct 29, 2008 at 9:14 AM, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Going through the tutorial brought up a question. Consider the functions:
>
> def f(a, L=[]):
>L.append(a)
>return L
>
> print f(3)
> print f(9)
> print f(7)
>
> def f1(i = 0):
>i = i + 1
>print
Hi all,
Going through the tutorial brought up a question. Consider the functions:
def f(a, L=[]):
L.append(a)
return L
print f(3)
print f(9)
print f(7)
def f1(i = 0):
i = i + 1
print i
f1()
f1()
f1()
f1()
Since the f accumulates the values in L, I was expecting to see i
printi
Antoon Pardon wrote:
> On 2006-10-12, Magnus Lycka <[EMAIL PROTECTED]> wrote:
>
>>Antoon Pardon wrote:
>>
>>>Well maybe he didn't intend that, but how is the reader of the
>>>documentation to know that? The reader can only go by how
>>>things are documented. If those are not entirely consistent
>>
On 2006-10-12, Magnus Lycka <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> Well maybe he didn't intend that, but how is the reader of the
>> documentation to know that? The reader can only go by how
>> things are documented. If those are not entirely consistent
>> with the intend of the progr
Antoon Pardon wrote:
> Well maybe he didn't intend that, but how is the reader of the
> documentation to know that? The reader can only go by how
> things are documented. If those are not entirely consistent
> with the intend of the programmer, that is not the readers
> fault.
I don't think I ever
On 6 Oct 2006 10:57:01 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
> Again that is not the fault of those that read the documentation. If
> this discinction can't be easily made in python 2.X, you can't fault
> the reader for coming to a conclusion that seems to follow rather
> naturally from ho
On Fri, 06 Oct 2006 12:42:08 +0200, Fredrik Lundh wrote:
> Antoon Pardon wrote:
>
>> IMO this is a very natural thought process for a python programmer.
>> So a python programmer seeing the first will tend to expect that
>> last call to work.
>
> on the other hand, if a Python programmer *writes
On 2006-10-06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>> IMO this is a very natural thought process for a python programmer.
>> So a python programmer seeing the first will tend to expect that
>> last call to work.
>
> on the other hand, if a Python programmer *writes* so
Antoon Pardon wrote:
> IMO this is a very natural thought process for a python programmer.
> So a python programmer seeing the first will tend to expect that
> last call to work.
on the other hand, if a Python programmer *writes* some code instead;
say, a trivial function like:
def calc
On 2006-10-06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> hanumizzle wrote:
>
>> Not sure exactly what is going on / being argued about in this
> > thread
>
> I'm describing best practices based on long experience of using and
> developing and teaching and writing about Python stuff. Others have
On 2006-10-06, hanumizzle <[EMAIL PROTECTED]> wrote:
> On 6 Oct 2006 09:21:11 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>> On 2006-10-06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> > Antoon Pardon wrote:
>> >
>> >> Is this general rules documeted somewhere? My impression is that readers
>> >>
hanumizzle wrote:
> Not sure exactly what is going on / being argued about in this
> thread
I'm describing best practices based on long experience of using and
developing and teaching and writing about Python stuff. Others have
other priorities, it seems.
> This doesn't say anything positiv
On 6 Oct 2006 09:21:11 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
> On 2006-10-06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > Antoon Pardon wrote:
> >
> >> Is this general rules documeted somewhere? My impression is that readers
> >> of the documentation will treat arguments as keyword argumen
On 2006-10-06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>> Is this general rules documeted somewhere? My impression is that readers
>> of the documentation will treat arguments as keyword arguments unless
>> this is explicitly contradicted.
>
> Sorry, I missed that this was
Antoon Pardon wrote:
> Is this general rules documeted somewhere? My impression is that readers
> of the documentation will treat arguments as keyword arguments unless
> this is explicitly contradicted.
Sorry, I missed that this was comp.lang.python.alternate.reality. My
mistake.
--
http://
On 2006-10-04, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Georg Brandl wrote:
>
>> This is an issue in most Python documentation: you're not told
>> if the described function is implemented in C, and if it is
>> keyword arg-enabled. The arguments must be given names though,
>> to be able to documen
Ben Finney wrote:
> Perhaps you meant something other than "if the documentation doesn't
> explicitly say that something is a keyword argument, it isn't", then.
I'm sure it's perfectly possibly to use your foot as a door stop, but
does that really mean that it is one?
--
http://mail.python.o
Fredrik Lundh <[EMAIL PROTECTED]> writes:
> Gabriel Genellina wrote:
>
> >> > the general rule is that if the documentation doesn't
> >> > explicitly say that something is a keyword argument, it isn't,
> >> > and shouldn't be treated as such.
>
> you guys need to look up the words "should" and "no
Gabriel Genellina wrote:
>> > the general rule is that if the documentation doesn't explicitly say
>> > that something is a keyword argument, it isn't, and shouldn't be
>> > treated as such.
>>
>> The first module I looked in to check this, it wasn't true. In the Queue
>> Module is isn't explicit
At Thursday 5/10/2006 11:41, Antoon Pardon wrote:
> the general rule is that if the documentation doesn't explicitly say
> that something is a keyword argument, it isn't, and shouldn't be treated
> as such.
The first module I looked in to check this, it wasn't true. In the Queue
Module is isn't
Fredrik Lundh wrote:
> Antoon Pardon wrote:
>
>
>>The first module I looked in to check this, it wasn't true. In the Queue
>>Module is isn't explicitly written that maxsize is a keyword argument yet
>>Queue.Queue(maxsize=9) works just fine.
>
>
> it's not a matter whether it works fine in any g
Antoon Pardon wrote:
> The first module I looked in to check this, it wasn't true. In the Queue
> Module is isn't explicitly written that maxsize is a keyword argument yet
> Queue.Queue(maxsize=9) works just fine.
it's not a matter whether it works fine in any given version of Python,
it's a mat
On 2006-10-04, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Georg Brandl wrote:
>
>> This is an issue in most Python documentation: you're not told
>> if the described function is implemented in C, and if it is
>> keyword arg-enabled. The arguments must be given names though,
>> to be able to documen
Georg Brandl wrote:
> This is an issue in most Python documentation: you're not told
> if the described function is implemented in C, and if it is
> keyword arg-enabled. The arguments must be given names though,
> to be able to document them.
the general rule is that if the documentation doesn't
Paul Rubin wrote:
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> repeat(object[, times])
>> Make an iterator that returns object over and over again. Runs
>> indefinitely unless the times argument is specified. ...
>>
>> My first impression from this, is that it is possible to call
>> this
On 2006-10-04, Antoon Pardon <[EMAIL PROTECTED]> wrote:
> On 2006-10-03, LaundroMat <[EMAIL PROTECTED]> wrote:
>> Suppose I have this function:
>>
>> def f(var=1):
>> return var*2
>>
>> What value do I have to pass to f() if I want it to evaluate var to 1?
>> I know that f() will return 2, but what
1 - 100 of 141 matches
Mail list logo
