ernel.Point import Point
> > p = Point()
>
> > now let's pass p into a func from .../openopt/kernel/file2.py and
> > check
> > from Point import Point
> > isinstance(p, Point)
>
> > So, it returns False!
>
> > p is , while Point is > openopt.kern
p into a func from .../openopt/kernel/file2.py and
> check
> from Point import Point
> isinstance(p, Point)
>
> So, it returns False!
>
> p is , while Point is openopt.kernel.Point.Point at 0x2048e20>
>
> [Subject: seems like a bug in isinstance()]
This is due to a pec
hi all,
suppose I've created a class Point in file .../openopt/kernel/Point.py
Consider the code in file .../somewhere/file1.py
from openopt.kernel.Point import Point
p = Point()
now let's pass p into a func from .../openopt/kernel/file2.py and
check
from Point import Point
isinstance(p, Point)
On 16Feb2011 12:01, Terry Reedy wrote:
| On 2/16/2011 1:32 AM, fireinice wrote:
| >I'm sorry, I found it should be the terminal width caused visual
| >problem, please kindly ignore this post.
|
| For future reference, the way to get more info about what is really
| in a string is to print its rep
On 2/16/2011 1:32 AM, fireinice wrote:
On Feb 16, 1:24 am, fireinice wrote:
Hi, all
I'm just working around to generate some fake file for parsing. and I
notice some weired thing happen.
time = str(random.randint(1000, ))
s_id = str(random.randint(1
fireinice, 16.02.2011 07:32:
On Feb 16, 1:24 am, fireinice wrote:
Hi, all
I'm just working around to generate some fake file for parsing. and I
notice some weired thing happen.
time = str(random.randint(1000, ))
s_id = str(random.randint(1000, 9
fireinice, 16.02.2011 07:24:
Hi, all
I'm just working around to generate some fake file for parsing. and I
notice some weired thing happen.
time = str(random.randint(1000, ))
s_id = str(random.randint(1000, ))
p_id = str(rando
On Feb 16, 1:24 am, fireinice wrote:
> Hi, all
> I'm just working around to generate some fake file for parsing. and I
> notice some weired thing happen.
> time = str(random.randint(1000, ))
> s_id = str(random.randint(1000, ))
>
Hi, all
I'm just working around to generate some fake file for parsing. and I
notice some weired thing happen.
time = str(random.randint(1000, ))
s_id = str(random.randint(1000, ))
p_id = str(random.randint(1000, 99
I see now. Thank you so much.
I think namespace is really a confusing part in Python.
On Friday, January 21, 2011 11:00:32 AM UTC-6, Peter Otten wrote:
> There are only two cases that matter: identical local/global namespaces and
> distinct local/global namespaces:
>
> >>> code = """\
> ... x =
longqian9...@gmail.com wrote:
> In pyhton 3.1, I found the following code will succeed with argument 1
> to 4 and fail with argument 5 to 9. It is really strange to me. I
> suspect it may be a buy in exec() function. Does anyone have some idea
> about it? Thanks.
>
>
> t1="""
> class foo:
> def
1
> > to 4 and fail with argument 5 to 9. It is really strange to me. I
> > suspect it may be a buy in exec() function. Does anyone have some idea
> > about it? Thanks.
>
> What makes you think it's a bug? Is there anything in the documentation
> of exec that sugg
gt; about it? Thanks.
What makes you think it's a bug? Is there anything in the documentation
of exec that suggests to you that some other behaviour should occur? What
version of Python are you using?
Without knowing what behaviour you expect and what behaviour you see, how
are we supposed to kno
In pyhton 3.1, I found the following code will succeed with argument 1
to 4 and fail with argument 5 to 9. It is really strange to me. I
suspect it may be a buy in exec() function. Does anyone have some idea
about it? Thanks.
t1="""
class foo:
def fun():
print('foo')
def m
--- On Wed, 11/3/10, MRAB wrote:
> [snip]
> The outer group is repeated, so it can match again, but the
> inner group
> can't match again because it captured all it could the
> previous time.
>
> Therefore the outer group matches and captures an empty
> string and the
> inner group remembers its
On 03/11/2010 06:32, Yingjie Lan wrote:
--- On Wed, 11/3/10, John Bond wrote:
I just explained that (I think!)! The outer capturing group
uses
repetition, so it returns the last thing that was matched
by the inner
group, which was an empty string.
According to yourself, the last match of the
On 03/11/2010 04:10, John Bond wrote:
On 3/11/2010 4:02 AM, MRAB wrote:
On 03/11/2010 03:42, Yingjie Lan wrote:
Matches an empty string, returns ''
The result is therefore ['Mar', '', '', 'lam', '', '']
Thanks, now I see it through with clarity.
Both you and JB are right about this case.
How
hen the last
match for the inner group must
also be empty.
Regards,
Yingjie
--- On Wed, 11/3/10, John Bond wrote:
> From: John Bond
> Subject: Re: Must be a bug in the re module [was: Why this result with the re
> module]
> To: python-list@python.org
> Date: Wednesday, November
--- On Wed, 11/3/10, John Bond wrote:
>3) then said there must be >=0 occurrences of what's inside it,
>which of course there is, so that has no effect.
>
>((.a.)*)*
Hi,
I think there should be a difference: unlike before,
now what's inside the outer group can match an empty
s
On 3/11/2010 4:23 AM, Yingjie Lan wrote:
--- On Wed, 11/3/10, MRAB wrote:
From: MRAB
Subject: Re: Must be a bug in the re module [was: Why this result with the re
module]
To: python-list@python.org
Date: Wednesday, November 3, 2010, 8:02 AM
On 03/11/2010 03:42, Yingjie Lan
wrote:
Therefore
OK, I've got that, and I have no problem with the capturing part.
My real problem is with the number of total matches.
*I think it should be 4 matches in total but findall
gives 6 matches*, for the new regex '((.a.)*)*'.
I'd love to know what you think about this.
Many thanks!
Yingjie
We'v
--- On Wed, 11/3/10, MRAB wrote:
> From: MRAB
> Subject: Re: Must be a bug in the re module [was: Why this result with the re
> module]
> To: python-list@python.org
> Date: Wednesday, November 3, 2010, 8:02 AM
> On 03/11/2010 03:42, Yingjie Lan
> wrote:
> Therefore th
--- On Wed, 11/3/10, John Bond wrote:
> Just to clarify - findall is returning:
>
> [ (only match in outer group, 1st match in inner group)
> , (only match in outer group, 2nd match in inner group)
> , (only match in outer group, 3rd match in inner group)
> , (only match in outer group, 4th mat
On 3/11/2010 4:02 AM, MRAB wrote:
On 03/11/2010 03:42, Yingjie Lan wrote:
Matches an empty string, returns ''
The result is therefore ['Mar', '', '', 'lam', '', '']
Thanks, now I see it through with clarity.
Both you and JB are right about this case.
However, what if the regex is ((.a.)*)* ?
On 3/11/2010 3:55 AM, John Bond wrote:
Could you please reconsider how would you
work with this new one and see if my steps
are correct? If you agree with my 7-step
execution for the new regex, then:
We finally found a real bug for re.findall:
re.findall('((.a.)*)*', 'Mary has a lamb')
[(''
On 03/11/2010 03:42, Yingjie Lan wrote:
Matches an empty string, returns ''
The result is therefore ['Mar', '', '', 'lam', '', '']
Thanks, now I see it through with clarity.
Both you and JB are right about this case.
However, what if the regex is ((.a.)*)* ?
Actually, in hindsight, my explan
Could you please reconsider how would you
work with this new one and see if my steps
are correct? If you agree with my 7-step
execution for the new regex, then:
We finally found a real bug for re.findall:
re.findall('((.a.)*)*', 'Mary has a lamb')
[('', 'Mar'), ('', ''), ('', ''), ('', 'lam'
> Matches an empty string, returns ''
>
> The result is therefore ['Mar', '', '', 'lam', '', '']
Thanks, now I see it through with clarity.
Both you and JB are right about this case.
However, what if the regex is ((.a.)*)* ?
--
http://mail.python.org/mailman/listinfo/python-list
> Your regex says "Zero or more consecutive occurrences of
> something, always returning the most possible". That's
> what it does, at every position - only matching emptyness
> where it couldn't match anything (findall then skips a
> character to avoid overlapping/infinite empty
> matches), and
On 03/11/2010 01:41, Yingjie Lan wrote:
From: John Bond
Subject: Re: Why this result with the re module
To: "Yingjie Lan"
Cc: python-list@python.org
Date: Tuesday, November 2, 2010, 8:09 PM
On 2/11/2010 12:19 PM, Yingjie Lan
wrote:
From: John Bond
Subject: Re: Why this result with the re module
Disagree in this case, where the whole regex
matches an empty string. Greadiness will match
as much as possible. So it will also match
the empty strings between consecutive
characters as much as possible, once
we have properly defined all the unique
empty strings. Because of greadiness,
fewer ma
> From: John Bond
> Subject: Re: Why this result with the re module
> To: "Yingjie Lan"
> Cc: python-list@python.org
> Date: Tuesday, November 2, 2010, 8:09 PM
> On 2/11/2010 12:19 PM, Yingjie Lan
> wrote:
> >> From: John Bond
> >> Subject: Re: Why this result with the re module
> > Firstly, than
> According to msg56377, the behaviour is "optimal" for regular
> expressions. Well, I use regular expressions a lot, and I
> still think it's a nuisance!
Thanks for bringing that up.
Using an otherwise 'dead' backlash to escape quotes
in raw strings seems like the black magic of
necromancy to
On 01/11/2010 03:30, Yingjie Lan wrote:
All backslashes in raw string literals are
interpreted literally.
(seehttp://docs.python.org/release/3.0.1/whatsnew/3.0.html):
All backslashes in syntactically-correct raw string
literals are interpreted literally.
That's a good way of putting it.
> > > All backslashes in raw string literals are
> interpreted literally.
> > > (seehttp://docs.python.org/release/3.0.1/whatsnew/3.0.html):
> >
> > All backslashes in syntactically-correct raw string
> literals are interpreted literally.
>
> That's a good way of putting it.
>
Syntactical correc
John Machin writes:
> On Oct 31, 11:23 pm, Yingjie Lan wrote:
> > Thanks! That looks weird to me ... doesn't this contradict with:
> >
> > All backslashes in raw string literals are interpreted literally.
> > (seehttp://docs.python.org/release/3.0.1/whatsnew/3.0.html):
>
> All backslashes in syn
On Oct 31, 11:23 pm, Yingjie Lan wrote:
> > > So I suppose this is a bug?
>
> > It's not, see
>
> >http://docs.python.org/py3k/reference/lexical_analysis.html#literals
>
> > # Specifically, a raw string cannot end in a single backslash
>
>
> > So I suppose this is a bug?
>
> It's not, see
>
> http://docs.python.org/py3k/reference/lexical_analysis.html#literals
>
> # Specifically, a raw string cannot end in a single backslash
Thanks! That looks weird to me ... doesn't this contradict with:
All
> So I suppose this is a bug?
It's not, see
http://docs.python.org/py3k/reference/lexical_analysis.html#literals
# Specifically, a raw string cannot end in a single backslash
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
Hi,
I tried this in the IDLE (version 3.1.2) shell:
>>> r'\'
SyntaxError: EOL while scanning string literal
But according to the py3k docs
(http://docs.python.org/release/3.0.1/whatsnew/3.0.html):
All backslashes in raw string literals are interpreted literally.
So I su
'''
C:\Documents and Settings\Administrator\Desktop>python wtf.py
301 Moved Permanently
b'
\n301 Moved\n301 Moved\nThe
document has mo
ved\nhttp://www.google.de/";>here.\r\n\r\n'
foo 5.328 secs
301 Moved Permanently
bar 241.016 secs
C:\Documents and Settings\Administrator\Desktop>
'''
import http.
Am 20.10.2010 14:32, schrieb Justin Ezequiel:
> On Oct 20, 12:47 am, Johannes Bauer wrote:
>>
> from urllib import request; request.URLopener().open("http://google.de";)
>
> aren't you supposed to call read on the return value of open?
> i.e.,
> request.URLopener().open("http://google.de";).re
On Oct 20, 8:32 pm, Justin Ezequiel
wrote:
> On Oct 20, 12:47 am, Johannes Bauer wrote:
>
>
>
> > >>> from urllib import request; request.URLopener().open("http://google.de";)
>
> aren't you supposed to call read on the return value of open?
> i.e.,
> .read()
better yet,
f = request.URLopener().
On Oct 20, 12:47 am, Johannes Bauer wrote:
>
> >>> from urllib import request; request.URLopener().open("http://google.de";)
>
aren't you supposed to call read on the return value of open?
i.e.,
request.URLopener().open("http://google.de";).read()
--
http://mail.python.org/mailman/listinfo/pytho
Johannes Bauer wrote:
> Hi,
>
> I've experienced the following behavior with Python3 of which I do not
> know if it's a bug or not. On two Python3.1 implementations, Python's
> urllib hangs when encountering a HTTP 301 (Redirect).
>
> The code to reproduce
4, in
> _open_generic_http
>response.status, response.reason, response.msg, data)
> File "/usr/lib/python3.1/urllib/request.py", line 1644, in http_error
>return self.http_error_default(url, fp, errcode, errmsg, headers)
> File "/usr/lib/python3.1/urllib/request.p
Hi,
I've experienced the following behavior with Python3 of which I do not
know if it's a bug or not. On two Python3.1 implementations, Python's
urllib hangs when encountering a HTTP 301 (Redirect).
The code to reproduce is a one-liner (actually, two-liner), Python from
Ubunt
On 9/3/10 4:35 AM, jc.lopes wrote:
Does anyone knows what is the proper way to submit a bug report to
pythonware PIL?
http://mail.python.org/mailman/listinfo/image-sig
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible b
On Sep 3, 10:35 am, "jc.lopes" wrote:
> Does anyone knows what is the proper way to submit a bug report to
> pythonware PIL?
>
> thanks
> JC Lopes
The Python Image SIG list http://mail.python.org/mailman/listinfo/image-sig
"Free Support: If you don't have a
Does anyone knows what is the proper way to submit a bug report to
pythonware PIL?
thanks
JC Lopes
--
http://mail.python.org/mailman/listinfo/python-list
In article <4b617f4...@dnews.tpgi.com.au>,
Lie Ryan wrote:
>
>f = open('input.txt', 'r+')
>for line in f:
>s = line.replace('python', 'PYTHON')
># f.tell()
>f.write(s)
>
>When f.tell() is commented, 'input.txt' does not change; but when
>uncommented, the f.write() succeeded writing in
* Anthony Tolle:
On Jan 28, 7:12 am, Lie Ryan wrote:
In the code:
"""
f = open('input.txt', 'r+')
for line in f:
s = line.replace('python', 'PYTHON')
# f.tell()
f.write(s)
"""
[snip]
My guess is that there are a few possible problems:
1) In this case, writing to file opened with
On Jan 28, 7:12 am, Lie Ryan wrote:
> In the code:
>
> """
> f = open('input.txt', 'r+')
> for line in f:
> s = line.replace('python', 'PYTHON')
> # f.tell()
> f.write(s)
> """
> [snip]
My guess is that there are a few possible problems:
1) In this case, writing to file opened with '
"help", "copyright", "credits" or "license" for more information.
>>> f = open('input.txt', 'r+')
>>> for line in f:
... s = line.replace('python', 'PYTHON')
... f.tell()
... f.write(s)
...
hello,
is there a way, in python, to create a splash window and when the
program has completed disappears by sending a msg to it? (I tried
creating two gtk windows but gtk_main doesn't seem to return unless it
gets closed.)
tia
Ron
--
http://mail.python.org/mailman/listinfo/python-list
unc_code', 'func_defaults', 'func_dict', 'func_doc'
, 'func_globals', 'func_name']
So i'm guessing that the attribute has been changed from func_code to
f_code but the inspect module wasn't updated to reflect that.
No, that wasn't the case. The argument of inspect.getargvalues() is a
'frame object' not 'function object'.
e.g.:
>>> inspect.getargvalues(inspect.currentframe())
You could argue that the error message is misleading (should be
TypeError instead), do you want a bug report on that?
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, Dec 29, 2009 at 6:38 PM, Irmen de Jong wrote:
> On 29-12-2009 23:22, inhahe wrote:
>
> inspect.getargvalues is used on frames, not on regular code objects.
> Maybe you were looking for inspect.getargspec?
>
That explains it!
I knew I'd done this before, I was just looking at the wrong fun
On 29-12-2009 23:22, inhahe wrote:
On Tue, Dec 29, 2009 at 5:11 PM, inhahe wrote:
On Tue, Dec 29, 2009 at 5:10 PM, inhahe wrote:
So i'm guessing that the attribute has been changed from func_code to
f_code but the inspect module wasn't updated to reflect that.
er i mean from f_code to fun
On 12/29/09, inhahe wrote:
> Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]
> on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
import inspect
def a(b=1): pass
> ...
inspect.getargvalues(a)
> Traceback (most recent call
On Tue, Dec 29, 2009 at 5:11 PM, inhahe wrote:
> On Tue, Dec 29, 2009 at 5:10 PM, inhahe wrote:
>>
>> So i'm guessing that the attribute has been changed from func_code to
>> f_code but the inspect module wasn't updated to reflect that.
>>
>
> er i mean from f_code to func_code
>
f_locals doesn'
On Tue, Dec 29, 2009 at 5:10 PM, inhahe wrote:
>
> So i'm guessing that the attribute has been changed from func_code to
> f_code but the inspect module wasn't updated to reflect that.
>
er i mean from f_code to func_code
--
http://mail.python.org/mailman/listinfo/python-list
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import inspect
>>> def a(b=1): pass
...
>>> inspect.getargvalues(a)
Traceback (most recent call last):
File "", line 1, in
File "C:\P
> You need to change the indexOf() calls to indexIn() calls on the QRegExp
> object:
>
> index = expression.indexIn(text, index + length)
Thank you so much ! After looking a bit more I found out that when
using indexOf the command :
length = expression.matchedLength()
was the one causing a p
On Wednesday 18 November 2009 11:47, Snouffy wrote:
> I've been trying to do some syntax highlighting using PyQt4. I ported
> the example given in the documentation of Qt4 to Python. It works fine
> on my computer at work (which has PyQt4 version 4.3.3) but doesn't on
> my home computer (which has
Hello everybody,
I've been trying to do some syntax highlighting using PyQt4. I ported
the example given in the documentation of Qt4 to Python. It works fine
on my computer at work (which has PyQt4 version 4.3.3) but doesn't on
my home computer (which has version 4.4.4) : it gets stuck in an
infin
lkcl wrote:
On Nov 7, 2:20 am, "Gabriel Genellina" wrote:
Yes, seems to be a bug. But given the current status of imputil, it's not
likely to be fixed; certainly not in 2.5 which only gets security fixes
now.
well, that bug's not the only one. the other one that i foun
Stef Mientki wrote:
Gabriel Genellina wrote:
En Fri, 06 Nov 2009 18:33:37 -0300, Stef Mientki
escribió:
I get an error compiling with pyjamas, in the standard module
imputil, _import_top_module
Note that imputil is undocumented in 2.5, deprecated in 2.6 and
definitively gone in 3.0
It w
On Nov 7, 2:20 am, "Gabriel Genellina" wrote:
> Yes, seems to be a bug. But given the current status of imputil, it's not
> likely to be fixed; certainly not in 2.5 which only gets security fixes
> now.
well, that bug's not the only one. the other one th
by adding the next 2 lines, everything works ok.
elif isinstance ( item, basestring ) :
module = self.fs_imp.import_from_dir ( str(item), name)
is this a bug ?
(I'm using Python 2.5.2 on Windows )
Yes, seems to be a bug. But given the current status of imputil, it&
Oops, missed out that... thanks
On Sun, Aug 30, 2009 at 2:25 PM, Jan Kaliszewski wrote:
> 30-08-2009 o 06:10:46 Abhishek Mishra wrote:
>
>> The single quote \' is the culprit.
>> When you say words = ["Hi", "Whats up", "Bye"] and try print words,
>> you get this -
>> ['Hi', 'Whats up', 'Bye']
>>
25-08-2009 o 22:51:14 Gleb Belov wrote:
I have two questions:
1) Is it possible and if so, how do I access each individual element?
Are there any indexes and what is the syntax?
It's a 'Read-The-Friendly-Manual' question.
(hint: library reference - Built-in Types - ...)
--
Jan Kaliszewski (
gt; 1) Is it possible and if so, how do I access each individual element?
> > Are there any indexes and what is the syntax?
>
> For the first element:
>
> >>> words[0]
> > 2) I just noticed that the first and the last words in the output are
> > enclosed in single qu
dexes and what is the syntax?
For the first element:
>>> words[0]
> 2) I just noticed that the first and the last words in the output are
> enclosed in single quotes, and the middle one is enclosed in double
> quotes. Is it a bug? If not, why does the output work that way?
The
quot;, "Bye!"]
>>> print words
['Hi!', "What's up?", 'Bye!']
I have two questions:
1) Is it possible and if so, how do I access each individual element?
Are there any indexes and what is the syntax?
2) I just noticed that the first and the last word
On Aug 5, 4:41 pm, sturlamolden wrote:
> On 5 Aug, 22:28, Jesse Noller wrote:
>
> >http://bugs.python.org/issue6653
>
> > In the future please use the bug tracker to file and track bugs with,
> > so things are not as lossy.
>
> Ok, sorry :)
>
> Also see Piet's comment here. He has a valid case ag
On 5 Aug, 22:28, Jesse Noller wrote:
> http://bugs.python.org/issue6653
>
> In the future please use the bug tracker to file and track bugs with,
> so things are not as lossy.
Ok, sorry :)
Also see Piet's comment here. He has a valid case against sys.exit in
some cases. Thus it appears that bot
On 5 Aug, 22:07, Piet van Oostrum wrote:
> Calling os.exit in a child process may be dangerous. It can cause
> unflushed buffers to be flushed twice: once in the parent and once in
> the child.
I assume you mean sys.exit. If this is the case, multiprocessing needs
a mechanism to chose between os
On Aug 5, 3:40 pm, sturlamolden wrote:
> On 5 Aug, 21:36, sturlamolden wrote:
>
> >http://svn.python.org/view/python/branches/release26-maint/Lib/multip...
>
> >http://svn.python.org/view/python/branches/release31-maint/Lib/multip...
>
> http://svn.python.org/view/python/trunk/Lib/multiprocessing
> sturlamolden (s) wrote:
>s> On 5 Aug, 15:40, Jesse Noller wrote:
>>> Sturla;
>>>
>>> That bug was fixed unless I'm missing something.
>s> It is still in SVN. Change every call to os._exit to sys.exit
>s> please. :)
Calling os.exit in a child process may be dangerous. It can cause
unflus
On Aug 4, 10:37 pm, erikcw wrote:
> Traceback (most recent call last):
> File "scraper.py", line 144, in
> print pool.map(scrape, range(10))
> File "/usr/lib/python2.6/multiprocessing/pool.py", line 148, in map
> return self.map_async(func, iterable, chunksize).get()
> File "/usr/li
On 5 Aug, 21:36, sturlamolden wrote:
> http://svn.python.org/view/python/branches/release26-maint/Lib/multip...
>
> http://svn.python.org/view/python/branches/release31-maint/Lib/multip...
http://svn.python.org/view/python/trunk/Lib/multiprocessing/forking.py?revision=65864&view=markup
--
http
On 5 Aug, 15:40, Jesse Noller wrote:
> Sturla;
>
> That bug was fixed unless I'm missing something.
It is still in SVN. Change every call to os._exit to sys.exit
please. :)
http://svn.python.org/view/python/branches/release26-maint/Lib/multiprocessing/forking.py?revision=66717&view=markup
http
On Aug 5, 1:21 am, sturlamolden wrote:
> On Aug 5, 4:37 am, erikcw wrote:
>
> > It's not always the same traceback, but they are always short like
> > this. I'm running Python 2.6.2 on Ubuntu 9.04.
>
> > Any idea how I can debug this?
>
> In my experience,multiprocessingis fragile. Scripts tend
On Aug 5, 4:37 am, erikcw wrote:
> It's not always the same traceback, but they are always short like
> this. I'm running Python 2.6.2 on Ubuntu 9.04.
>
> Any idea how I can debug this?
In my experience, multiprocessing is fragile. Scripts tend fo fail for
no obvious reason, case processes to b
Hi,
I'm trying to get multiprocessing to working consistently with my
script. I keep getting random tracebacks with no helpful
information. Sometimes it works, sometimes it doesn't.
Traceback (most recent call last):
File "scraper.py", line 144, in
print pool.map(scrape, range(10))
Fil
On Sun, 2009-08-02 at 14:14 +, Albert van der Horst wrote:
> >This is actually quite thoroughly untrue. In python, *indentation*
> is
> >significant. Whitespace (internal to a line) is not. You can even
> call
> >methods like this if you want:
>
> You totally don't get it. You describe how
In article ,
J. Cliff Dyer wrote:
>On Fri, 2009-07-17 at 20:53 +, Albert van der Horst wrote:
>> Because unlike in algol 68 in python whitespace is relevant,
>> we could get by with requiring whitespace:
>> x= -q # okay
>> a> 8 ** -2
Maybe the IDE is the best place to warn you of something like that.
You could have an IDE where you specify which language you're more
familiar with and then have it display warnings likely to be relevant
to you. People could collaborate to add support for gradually more
niche languages.
Python
J. Cliff Dyer wrote:
On Fri, 2009-07-17 at 20:53 +, Albert van der Horst wrote:
Because unlike in algol 68 in python whitespace is relevant,
we could get by with requiring whitespace:
x= -q # okay
a
This is actually quite thoroughly untrue. In python,
On Fri, 2009-07-17 at 20:53 +, Albert van der Horst wrote:
> Because unlike in algol 68 in python whitespace is relevant,
> we could get by with requiring whitespace:
> x= -q # okay
> a 8 ** -2 # okay
This is actually quite thor
In article ,
Gabriel Genellina wrote:
>En Mon, 06 Jul 2009 00:28:43 -0300, Steven D'Aprano
> escribi?:
>> On Mon, 06 Jul 2009 14:32:46 +1200, Lawrence D'Oliveiro wrote:
>>
>>> I wonder how many people have been tripped up by the fact that
>>>
>>> ++n
>>>
>>> and
>>>
>>> --n
>>>
>>> fail si
On Jul 7, 2:00 pm, Steven D'Aprano wrote:
> On Mon, 06 Jul 2009 22:18:20 -0700, Chris Rebert wrote:
> >> Not so rare. Decimal uses unary plus. Don't assume +x is a no-op.
> [...]
> > Well, yes, but when would you apply it twice in a row?
>
> My point was that unary + isn't a no-op, and therefore n
In message , MRAB
wrote:
> I wonder whether the problem with assignment in conditionals in C is due
> to the assignment operator being "=". If it was ":=", would the error
> still occur?
One of the original C designers, Kernighan or Ritchie, admitted that he made
the assignment operator "=" ins
In message <4a538a71$0$30236$9b4e6...@newsspool1.arcor-online.net>, Stefan
Behnel wrote:
> Lawrence D'Oliveiro wrote:
>>
>> I wonder how many people have been tripped up by the fact that
>>
>> ++n
>>
>> and
>>
>> --n
>>
>> fail silently for numeric-valued n.
>
> I doubt that there ar
>> But this academic discussion is honestly a little pointless. The OP
>> was referring to a expectation, coming from C, that is not fulfilled
>> in python. What's wrong with mentioning it somewhere for the sake of
>> helping C programmers?
>>
> And where does one stop? After all, my primary
-Original Message-
From: Dennis Lee Bieber [mailto:wlfr...@ix.netcom.com]
Sent: Tuesday, 7 July 2009 4:45 p.m.
To: python-list@python.org
Subject: Re: A Bug By Any Other Name ...
On Mon, 6 Jul 2009 19:48:39 -0700, Daniel Fetchinson
declaimed the following in
gmane.comp.python.general
Lawrence D'Oliveiro wrote:
> I wonder how many people have been tripped up by the fact that
>
> ++n
>
> and
>
> --n
>
> fail silently for numeric-valued n.
I doubt that there are many. Plus, you misspelled them from the more obvious
n++
and
n--
which *do* fail with
Daniel Fetchinson wrote:
and my point is that users
are most of time correct when they assume that something will work the
same way as in C.
Oh, really ? They would surely be wrong if they'd expect the for loop to
have any similarity with a C for loop, or - a *very* common error - if
they'd expe
>> and my point is that users
>> are most of time correct when they assume that something will work the
>> same way as in C.
>
> Oh, really ? They would surely be wrong if they'd expect the for loop to
> have any similarity with a C for loop, or - a *very* common error - if
> they'd expect assignme
Yes, there are plenty of languages other than Java and C, but the
influence of C is admittedly huge in Python. Why do you think loops
are called "for", conditionals "if" or "while", functions return via
"return", loops terminate via "break" and keep going via "continue"
and
101 - 200 of 547 matches
Mail list logo
