t;, re.I | re.U))
> Out[2]: '<_sre.SRE_Match object at 0x027CDB10>'
>
> "[^\d\W_]+" means something like "one or more (+) of 'not (a digit, a
> non-word, an underscore)'.
>
Nice, I am seriously considering this, if only because I have less t
Op 09-03-15 om 16:17 schreef Tim Chase:
> On 2015-03-09 15:29, Antoon Pardon wrote:
>> Op 09-03-15 om 13:50 schreef Tim Chase:
>>>> (?:(?!_|\d)\w)\w+
>>> If you don't have to treat it as an atom, you can simplify that to
>>> just
>>>
>
Op 09-03-15 om 17:11 schreef Steven D'Aprano:
> Antoon Pardon wrote:
>
>> I am using PLY for a parsing task which uses re for the lexical
>> analysis. Does anyone
>> know what regular expression to use for a sequence of letters? There is
>> a class for alphanum
On 03/19/2015 10:35 AM, martin.spa...@gmail.com wrote:
> The following code is challenging my sanity, in my understanding of the
> documentation this should pass, given that getLogger is supposed to return
> the root logger and the root logger should be called 'root'.
Where do you get the idea t
On 03/28/2015 11:43 AM, Steven D'Aprano wrote:
> On Sat, 28 Mar 2015 08:53 pm, Steven D'Aprano wrote:
>
>
>> It saves typing. It might even allow a micro-optimization in the generated
>> bytecode (see below).
> Oops, I forgot to include the "see below" bit.
>
> Comparing
>
> a = a.spam()
>
> a .=
On 04/16/2015 09:46 AM, alister wrote:
> what I find strange is that although these programmers initially disliked
> forced indentation they were voluntarily indenting there existing code
> anyway. Take a look at your existing code base & see if this would indeed
> be the case.
The problem is
On 04/16/2015 11:34 AM, Chris Angelico wrote:
> On Thu, Apr 16, 2015 at 6:47 PM, Antoon Pardon
> wrote:
>> On 04/16/2015 09:46 AM, alister wrote:
>>
>>> what I find strange is that although these programmers initially disliked
>>> forced indentation they were
On 04/16/2015 12:43 PM, Steven D'Aprano wrote:
> On Thursday 16 April 2015 20:09, Antoon Pardon wrote:
>
>> I beg to differ. The most common occurence is a loop with a break
>> condition in the middle I would prefer such a loop to be written as
>> follows:
>>
On 04/16/2015 06:07 AM, Blake McBride wrote:
> Greetings,
>
> I am new to Python. I am sorry for beating what is probably a dead horse but
> I checked the net and couldn't find the answer to my question.
>
> I like a lot of what I've seen in Python, however, after 35 years and
> probably a dozen
tations, one can't have a quarrel
with how python forces you to indent.
A choice was made and although I would have preferred otherwise, I can
live with it.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
I also think that one doesn't need to discard a language just because one
doesn't like this particular feature. One can think the other characteristics
of the language are positive enough one can live with this small annoyance.
--
Antoon Pardon.
--
https://mail.python.org/mailman/listinfo/python-list
ticular kind of bug.
The fact that braces protect against a kind of bug you care less about,
is just your preference. That doesn't mean a different preference is
somehow worthy of ridicule.
Mistakes of all kinds happen and I see no reason to ridicule someone for
wishing protect against one kind of mistake, while yourself having the
protection you like.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
rror as an error specific to the implementation
and want an exception independent of your implementation: catch the
IndexError and raise one you specified yourself.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
cult to discover bugs instead of letting a possible
misleading token or syntax prevent you from implementing something
useful.
In the second case you just state why you think an assignment in a
condition is harmful. No need to hide behind awkward syntax.
--
Antoon Pardon
--
https://mail.python
; overridden that).
This is a common python myth. That is selectively used when convenient and
ignored when that is convenient.
Try overriding None, True or False in python3 and see what happens.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
Op 11-05-15 om 12:40 schreef Mark Lawrence:
> On 11/05/2015 11:15, Antoon Pardon wrote:
>> Op 10-05-15 om 19:28 schreef Gary Herron:
>>
>>> Common Python thought:: "We're all adults here."If you want to
>>> override a builtin within your ow
Op 11-05-15 om 13:58 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> Which is exactly the point! They were turned into keywords because the
>> developers didn't want to allow them being overridden. There is no a
>> priori reason why we should turn "True" i
Op 11-05-15 om 14:34 schreef Steven D'Aprano:
> On Mon, 11 May 2015 09:39 pm, Antoon Pardon wrote:
>
>> There is no
>> a priori reason why we should turn "True" into a keyword and allow
>> "int" in the builtins.
> Why should there be an *a prior
Op 11-05-15 om 16:03 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> The point is that all too often someone wants to defend a specific
>> choice the developers have made and cites some general rule or
>> principle in support, ignoring the fact that python breaks that
&g
Op 11-05-15 om 16:13 schreef Chris Angelico:
> Why does Python have most built-ins as simply looked-up names that can
> be overridden? Because otherwise, there would be a veritable ton of
> keywords:
But that doesn't answer the question why the developers chose "True" to be a
keyword and "int" to
Op 11-05-15 om 17:44 schreef Steven D'Aprano:
> On Mon, 11 May 2015 11:27 pm, Antoon Pardon wrote:
>
>> The point is that all too often someone wants to defend a specific choice
>> the developers have made and cites some general rule or principle in
>> support, ignorin
Op 12-05-15 om 15:56 schreef Steven D'Aprano:
> On Tue, 12 May 2015 09:55 pm, Antoon Pardon wrote:
>
>> Op 11-05-15 om 16:13 schreef Chris Angelico:
>>
>>> Why does Python have most built-ins as simply looked-up names that can
>>> be overridden? Because
Op 13-05-15 om 02:19 schreef Gregory Ewing:
> Antoon Pardon wrote:
>> But that doesn't answer the question why the developers chose "True"
>> to be a
>> keyword and "int" to be a looked-up name.
>
> Probably because True, False and None are very
On 07/13/2015 01:28 PM, Chris Angelico wrote:
> On Sun, Jul 12, 2015 at 8:20 AM, Ian Burnette wrote:
>> [ About tail recursion ]
>>
> When a function is purely tail-recursive like this, it's trivial to
> convert it at the source code level:
>
> def factorial(n):
> acc = 1
> while n > 0:
>
On 07/13/2015 02:34 PM, Chris Angelico wrote:
>
>>> Warping your code around a recursive solution
>>> to make it into a perfect tail call usually means making it look a lot
>>> less impressive; for instance,
>> And sometimes your problem is very easily solved by a number of functions
>> that tail c
On 07/13/2015 04:05 PM, Chris Angelico wrote:
> On Mon, Jul 13, 2015 at 11:55 PM, Antoon Pardon
> wrote:
>> On 07/13/2015 02:34 PM, Chris Angelico wrote:
>>>>> Warping your code around a recursive solution
>>>>> to make it into a perfect tail call usu
unity
in general.
I expect any example given, to be used as a contest by those reading,
for finding
the least warped alternative and then using that to dismiss the example.
So I really don't feel compelled to search through my code in the hope
of finding
an example that would persuade someone
On 07/14/2015 10:34 AM, Ian Kelly wrote:
> On Tue, Jul 14, 2015 at 1:26 AM, Antoon Pardon
> wrote:
>> I expect any example given, to be used as a contest by those reading,
>> for finding
>> the least warped alternative and then using that to dismiss the example.
>
On 07/14/2015 03:43 PM, Chris Angelico wrote:
> On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>>> On Tue, Jul 14, 2015 at 10:28 PM, Marko Rauhamaa wrote:
I would rather optimize by default and disable optimizations with
--debug or equivalent.
>>> That as
ils, you no longer get the stack traces
> you need to debug the problem.
You don't need those stack traces to debug the problem. The only thing useful
they generally contain is the line that failed. Traceback records of the moment
some subcalculation in some subcall went wrong are not available. So TCO will
not be a real burden here.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
On 07/15/2015 02:41 AM, Terry Reedy wrote:
> On 7/14/2015 10:02 AM, Antoon Pardon wrote:
>> On 07/14/2015 03:43 PM, Chris Angelico wrote:
>>> On Tue, Jul 14, 2015 at 11:38 PM, Marko Rauhamaa
>>> wrote:
>
>>>> No, tail call optimization doesn't c
= 0 else even(n - 1)
How do I rewrite those with your module?
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
;> pass
>>
>> x = who_knows()
> Yes, that's what I'm saying. The implementation would be free to assign
> any value whatsoever to x.
And can you explain why this would be needed foor smooth tail call elimination?
--
Antoon Pardon.
--
https://mail.python.org/mailman/listinfo/python-list
On 07/16/2015 12:43 AM, Gregory Ewing wrote:
> Antoon Pardon wrote:
>> But it doesn't need to be all or nothing. How about the following
>> possibility.
>> When the runtime detects a serie of tail calls, it will keep the bottom three
>> and the top thre
On 07/15/2015 11:19 PM, Terry Reedy wrote:
> On 7/15/2015 5:29 AM, Antoon Pardon wrote:
>>
>> Can you explain how you would do mutual recursive functions?
>> Suppose I start with the following:
>>
>> def even(n):
>> True if n == 0 else odd(n - 1)
>>
On 07/16/2015 10:07 AM, Steven D'Aprano wrote:
> On Wednesday 15 July 2015 19:29, Antoon Pardon wrote:
>
>> Suppose I start with the following:
>>
>> def even(n):
>> True if n == 0 else odd(n - 1)
>>
>> def odd(n):
>> False if n == 0
On 07/16/2015 01:11 PM, Chris Angelico wrote:
> On Thu, Jul 16, 2015 at 8:41 PM, Antoon Pardon
> wrote:
>>> Fixing the obvious mistake (failing to return anything) leads to the next
>>> mistake. When all you have is a hammer, everything looks like a nail.
>>>
&g
On 07/16/2015 01:45 PM, Chris Angelico wrote:
> On Thu, Jul 16, 2015 at 5:31 PM, Antoon Pardon
> wrote:
>>
>> I would say, that someone should get over himself.
>> Traceback are not the only or even the most useful
>> tool for debugging code. The current stack tra
On 07/16/2015 03:47 PM, Chris Angelico wrote:
> On Thu, Jul 16, 2015 at 11:35 PM, Antoon Pardon
> wrote:
>> Any collection of functions that tail calls each other can rather
>> trivially be turned into a state machine like the above. You can
>> just paste in the code of
On 07/16/2015 04:00 PM, Chris Angelico wrote:
> On Thu, Jul 16, 2015 at 11:56 PM, Antoon Pardon
> wrote:
>> Fine, I should have been more clear.
>>
>> The stack trace as it is generally produced on stderr after an uncought
>> exception, doesn't contain the v
On 07/16/2015 04:27 PM, Chris Angelico wrote:
> On Fri, Jul 17, 2015 at 12:21 AM, Antoon Pardon
> wrote:
>>> My point was that I have yet to see
>>> anything that demands TCO and can't be algorithmically improved.
>> And how is this point relevant? Why shoul
On 07/17/2015 01:46 AM, Chris Angelico wrote:
> Open for bikeshedding: What should the keyword be? We can't use
> "exec", which would match Unix and shell usage, because it's already
> used in a rather different sense in Python. Current candidates:
> "transfer", "goto", "recurse", and anything else
On 07/16/2015 09:34 PM, Terry Reedy wrote:
> On 7/16/2015 3:45 AM, Antoon Pardon wrote:
>> On 07/15/2015 11:19 PM, Terry Reedy wrote:
>>>
>>> I believe that this pattern should work with any set of mutually
>>> recursive functions that always call each other in
On 07/16/2015 08:58 PM, Steven D'Aprano wrote:
>> Nice of you to illustrate how being pedantic about something, can
>> make a response useless with regard to the intended original question.
> Just because your intention in giving that code was X, doesn't mean that
> others cannot use that code to a
On 07/16/2015 06:43 PM, Chris Angelico wrote:
> On Fri, Jul 17, 2015 at 12:32 AM, Antoon Pardon
> wrote:
>
>> What is unclear about "as it is generally produced on stderr"? That you
>> can do a whole lot of stuff, doesn't mean that this whole lot of stuff
On 07/17/2015 01:05 PM, Chris Angelico wrote:
> On Fri, Jul 17, 2015 at 8:48 PM, Antoon Pardon
> wrote:
>> Just wondering, are traceback records of generators available? They are
>> if an exception is raised in the generator itself, but what if an exception
>> is raised in
On 07/17/2015 01:49 PM, Chris Angelico wrote:
> On Fri, Jul 17, 2015 at 9:43 PM, Antoon Pardon
> wrote:
>
>
>> Sure, but in this case, the generator is still active. The Runtime
>> would be able to jump to and somehow activates it's stack record
>> for the next
On 07/19/2015 07:39 AM, Steven D'Aprano wrote:
> In Python 2, integer literals with leading zeroes are treated as octal, so
> 09 is a syntax error and 010 is 8.
>
> This is confusing to those not raised on C-style octal literals, so in
> Python 3 leading zeroes are prohibited in int literals. Octa
On 07/19/2015 02:21 AM, Chris Angelico wrote:
> On Sun, Jul 19, 2015 at 9:32 AM, Gregory Ewing
> wrote:
>> Personally I'd be fine with your initial syntax, but
>> something else might be needed to get it past Guido.
>> He didn't like my 'cocall f()' construct in PEP 3152,
>> which is syntacticall
; just used integers.
>>
>> Laura
>
> This type of information should be stored as a string not any type of
> numeric format, if you are not performing maths on it then it is a string
> & not a number.
Does the same condition hold for strings? If you are not pe
I'm using python 3.4.2 on debian 8.
This is the code:
8< =
import sys
write = sys.stdout.write
from math import pi
frac = 3
for a in range(2 * frac):
write("%2d: %6.4f\n" % (a, a * pi / frac))
= 8<
Now when this code is written in a file and executed
I get the expected
equivallent to : blocking=True, timeout=0
Can someone explain why these different signatures, or
should I consider this a relict from the past?
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
been a long time since I used it, but it was for something
similar.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
3.4.2 due
to retain backward compatibility.
So what is the supposed correct way to handle this? Preferably one
that works when additional levels have been introduced.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
really happy with them. I think python
should give the second result in both cases.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
Op 02-09-15 om 11:50 schreef Peter Otten:
> Antoon Pardon wrote:
>
>> I am writing an application that will do the necessary logging.
>> However I want the level of logging to be deciced by a value
>> in a config file. Like the following:
>>
>> loglevel = WARNI
"thing" more
> than once on the LHS.
That is rather extreme. It would mean we avoid the following:
a[i], b[i] = b[i], a[i] # references i twice on the LHS.
a[i], a[j] = a[j], a[i] # references a twice on the LHS.
I think a better rule would be: Don't reference and bind
the same "thing" on the LHS.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
Op 05-09-15 om 02:05 schreef Vladimir Ignatov:
>> To me, marking a variable as global in a large number of functions is
>> a code smell that indicates that you're probably overusing globals.
>> Lua is an example of a language that takes the opposite approach: in
>> Lua, every variable is global unl
have a conditional expression. But at that
time Guido used that poll as an indication there was not enough support.
So colour me a bit sceptical when Guido comes with such a poll.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
s what you need
to do, that is the explicit way.
Not needing to declare local variables, is an implicit way, since it is
behaviour
depending on something not being indicated.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
Op 08-09-15 om 11:22 schreef Mark Lawrence:
> On 08/09/2015 09:59, Antoon Pardon wrote:
>
>> There the poll indicated no specific proposal had a majority, so for
>> each
>> specific proposal one could say it didn't have popular support, but the
>> majority s
d you are screwed.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
evelopers have only limited
time, and they get to choose what they consider a priority and what they don't.
And if they think other things have higher priority, fine by me. But don't
come with, no support/consensus with the users, because if the dev-team thinks
something is a good id
are lousy. Assignment is an expression?
What is wrong with that?
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
Op 10-09-15 om 16:21 schreef Michael Torrie:
> On 09/10/2015 01:27 AM, Antoon Pardon wrote:
>> Op 09-09-15 om 19:55 schreef Steven D'Aprano:
>>> In fairness to the C creators, I'm sure that nobody back in the early
>>> seventies imagined that malware and
that introducing the "as v" possibily only
in while and if statements would mainly enlargen my frustration.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
Op 11-09-15 om 13:59 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> I just don't get why people want to introduce special cases in python.
>> Why allow such a construct only in while and if? Why not just allow
>> it generally as an assignment expression?
>>
>&
assignments.
Sure an assignment has a side effect. But so has ls.pop(). So something having
a side-effect and a value is not unheard of even within a python context.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
Op 16-09-15 om 03:13 schreef Steven D'Aprano:
> On Mon, 14 Sep 2015 06:30 pm, Antoon Pardon wrote:
>
>> Op 12-09-15 om 05:48 schreef Steven D'Aprano:
>>> I believe I already acknowledged that assignment-as-expression was fine
>>> if it avoided the =
value from the class.
However on the left hand, python will create an attribute for self and assign
the
value to it. Python will not rebind the class variable.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
Op 29-09-15 om 13:17 schreef Anssi Saari:
> Antoon Pardon writes:
>
>> Op 29-09-15 om 11:27 schreef ple...@gmail.com:
>>> I have a perplexing problem with Python 3 class variables. I wish to
>>> generate an unique ID each time an instance of GameClass is
>>>
'm sure most others could have
> too.
Yes, they were just to busy to try pushing the OP in an other direction, for
them to answer the question.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
enough people then insist on a better alternative
to deal with the problem totally ignoring that this better alternative
may be totally useless in the original context.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
Op 07-11-15 om 04:43 schreef Ben Finney:
> Bartc writes:
>
>> Is there no way then in Python to declare:
>>
>>pi = 3.141519 # etc
>>
>> and make it impossible to override?
> No, and it would be a bad thing if that were something a library author
> could forbid.
>
> Python assumes the progr
cide on conditions. Once one party is obligated it is no longer consenting.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
Op 14-11-15 om 04:11 schreef Michael Torrie:
> On 11/10/2015 03:03 AM, Antoon Pardon wrote:
>> Op 10-11-15 om 00:29 schreef Ben Finney:
>>>
>>> Who is doing what to whom? The user of the library isn't doing anything
>>> to the library author, so what is i
Op 19-11-15 om 00:22 schreef Chris Angelico:
> On Thu, Nov 19, 2015 at 10:14 AM, BartC wrote:
>> On 18/11/2015 22:11, Ian Kelly wrote:
>>>
>>> On Wed, Nov 18, 2015 at 2:08 PM, fl wrote:
Hi,
I have tried the below function and find that it can remember the
previous
se
Op 19-11-15 om 13:45 schreef Steven D'Aprano:
> On Thu, 19 Nov 2015 10:41 pm, BartC wrote:
>
>
>> I expect the version with the default argument to be
>> exactly the same as the last lot of calls, namely for:
>>
>> fn()
>> fn()
>> fn()
>>
>> to be equivalent to:
>>
>> temp=[]
>> fn(temp)
>> temp=
Op 24-11-15 om 13:07 schreef Chris Angelico:
> On Tue, Nov 24, 2015 at 10:36 PM, Antoon Pardon
> wrote:
>>>> So, looking at some source code, a default value for certain types is only
>>>> certain to be that value for the very first call of that function?
>>
Op 20-11-15 om 01:27 schreef Ned Batchelder:
> On Thursday, November 19, 2015 at 7:11:52 PM UTC-5, BartC wrote:
>> On 19/11/2015 22:55, Michael Torrie wrote:
>>> On 11/19/2015 02:21 PM, BartC wrote:
(Python returns 42; so that means my languages are more dynamic than
Python? That's hard t
Op 19-11-15 om 19:20 schreef Mark Lawrence:
> On 19/11/2015 17:30, BartC wrote:
>> On 19/11/2015 16:01, Steven D'Aprano wrote:
>>> On Fri, 20 Nov 2015 12:19 am, BartC wrote:
>>
>>> You know, for somebody who claims to design and implement your own
>>> languages, you sometimes go to a remarkable eff
Op 20-11-15 om 02:05 schreef Steven D'Aprano:
> On Fri, 20 Nov 2015 04:30 am, BartC wrote:
>
>> On 19/11/2015 16:01, Steven D'Aprano wrote:
> [...]
>
>> The whole concept of 'mutable' default is alien to me. A default is just
>> a convenient device to avoid having to write:
>>
>>fn(0) or fn(
Op 24-11-15 om 15:00 schreef Chris Angelico:
> On Wed, Nov 25, 2015 at 12:43 AM, Antoon Pardon
> wrote:
>> I think that part of the problem is, that [] is not a constant object. So
>> that when you see a line like
>>
>> ls = []
>>
>> It behaves mo
Op 20-11-15 om 13:12 schreef Ned Batchelder:
> On Friday, November 20, 2015 at 6:59:54 AM UTC-5, BartC wrote:
>> On 20/11/2015 01:05, Steven D'Aprano wrote:
>>> On Fri, 20 Nov 2015 04:30 am, BartC wrote:
>>>
On 19/11/2015 16:01, Steven D'Aprano wrote:
>>> [...]
>>>
The whole concept of 'm
Op 20-11-15 om 14:04 schreef Chris Angelico:
> On Fri, Nov 20, 2015 at 11:39 PM, BartC wrote:
>> * The refusal to acknowledge that the def fn(a=[]) syntax is misleading.
>> (What value will a have when you call fn()? The true answer is that you
>> can't tell.)
>
> It isn't misleading. The default
', ...]
"ls '*.py'" -> ['ls', '*.py']
Does something like this already exist? I looked around but seem to find
only things only partially do things like this, like shlex.split.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
On 16-06-14 12:06, Chris Angelico wrote:
> def shell_split(cmd):
> return subprocess.check_output("""python -c 'import sys;
> print("\\0".join(sys.argv[1:]))' """+cmd,shell=True)[:-1].split("\0")
Nice idea, unfortunatly it doesn't work in python3.3
>>> shell_split("ls *.py")
Traceback (most
On 16-06-14 13:01, Peter Otten wrote:
> Antoon Pardon wrote:
>
>> I am looking for an interface that takes a string as argument. The
>> string is to be treated as if it is a command line and transformed into
>> an argv list.
>>
>> "ls file" ->
;t
> be quite as clear.) But he said "treated as a command line". So that's
> exactly what I did. :) He didn't ask about globbing, he asked about
> doing what the shell does... maybe he wants variable expansion too?
That would be interresting too. The problem with your
talking about.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
for b in block
process(b)
Otherwise I could write it more as follows:
for block in iter(partial(RawStream.read, 1024), io.EOF):
for b in block
process(b)
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
On 30-07-14 13:37, Peter Otten wrote:
> Antoon Pardon wrote:
>
>> Taking this in consideration I think the io.RawIOBase.read got it
>> backwards.
>>
>> The documentation says the following:
>>
>> | If 0 bytes are returned, and size was not 0, this indic
On 23-08-14 01:20, Terry Reedy wrote:
> On 8/22/2014 10:26 AM, luofeiyu wrote:
>> System:win7+python34.
>> class Contact(object):
>> def __init__(self, first_name=None, last_name=None,
>> display_name=None, email=None):
>> self.first_name = first_na
t.
I think your priorities are off. I often enought see people posting code
that was copy-pasted from an interactive python session complete with
lines beginning with >>>. As far as I know nobody has complained about
that even if it needs more manipulation before you can run the code than
an extra indent.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
colour_cycle)# → "Blue"
> next(colour_cycle)# → "Red"
> next(colour_cycle)# → "Blue"
> next(colour_cycle)# → "Red"
>
> for colour in colour_cycle:
> # … loops indefinitely
> # with ‘colour’ bou
r it this doesn't work 100% correctly. Last time I tried
using this, it didn't work with an exception instance but
only with an execption class as parameter. There was a discussion at
http://mail.python.org/pipermail/python-dev/2006-August/068158.html
about this. I don't know how
ead for instance to
indicate a timeout for the latter and the latter catches that exception
and tries again what it was doing in a loop, that is entirely the
problem of the author of that loop and not of the abilty of one thread
throwing an exception in an other.
Unless of course there may be a lot of su
leads to "UnboundLocalError: local variable 'logger' referenced before
assignment").
Any ideas on the best way to implement this?
How about two global references:
globallogger = logger = logging.getLogger('my.module.name')
def function(self):
logger = globallogger.g
I have an import problem I can't figure out.
I am using python 2.6.6 on a debian box
In one directory (pylib) I have a file misc.py and
the file testutil.py.
testutil.py --
print "in", __name__
from misc import Rec
-
On 01/11/2012 02:57 PM, Peter Otten wrote:
Antoon Pardon wrote:
I have an import problem I can't figure out.
I am using python 2.6.6 on a debian box
In one directory (pylib) I have a file misc.py and
the file testutil.py.
from misc import Rec
ImportError: cannot i
1201 - 1300 of 1820 matches
Mail list logo
