Re: Don't feed the troll...
On Thu, Jun 27, 2013 at 12:13 PM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: So what do you think would be a good approach towards people who are behaving in conflict with this wish of yours? Just bluntly call them worse than the troll or try to approach them in a way that is less likely to antangonize them? Inform them that their behavior is damaging the list atmosphere, and ask them to please knock it off. Shaming the behavior works too, but I'd prefer to go with the former. The collective experience of theachers is that punishment for bad performance works, despite research showing otherwise. Flaming a troll is not punishing to them. Now as far as I am concerned you can be as blunt as you want to be. I just don't understand why you think you should be so careful to Nikos, while at the same time you saw no need for careful wording here. Nobody is suggesting that we should make any effort to try to avoid hurting Nikos' feelings, contrary to what you seem to be implying here. I am implying nothing. I'm just pointing out the difference between how rurpy explains we should behave towards Nikos and how he behaved towards the flamers. If there is some sort of implication it is with rurpy in that difference and not with me in me pointing it out. Your statement I just don't understand why you think you should be so careful to Nikos implies that somebody thinks we should be careful to Nikos, i.e. be careful to not hurt his feelings. At least that is how I read it, and I don't think it is true. Be as blunt as you want with him, but please recognize that troll baiting /does not work/ as a means of making the troll go away and only serves to further degrade the list. It's not clear to me what you are precisely saying here. Do you think being blunt is a form of troll baiting or not? Because my impression of those who are bothered by the flamers, was that being blunt was just a form of troll baiting and would just cause similar kind of list degradation. No. Flaming carries an emotional response, which signals to the troll that they've struck a nerve and can help incite them. A blunt, non-emotional response is less likely to end up functioning as positive reinforcement in that way. That said, the best response to a troll is still no response at all. Do you think being blunt is a good way in keeping a welcoming and postive atmosphere in this group? I think it's better than being openly hostile. And speaking for myself, if somebody has a problem with my own behavior then I would prefer that they be blunt about it than cover it up with a false friendliness. I am not so sure it would be counter-productive. A joint flaming of a troll can be an effective way to increase coherence in a group. Well, if flaming ever becomes the prevailing culture of the list, then I'm out. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is the semantics meaning of 'object'?
On 26/06/2013 9:19 AM, Mark Janssen wrote: Did you ever hear of the Glass Bead Game? Which was Hesse's condemnation of the pure-academic-understanding-unbound-by-pragmatic-use approach as mental masturbation, It was not. He was conflicted. On the one hand he knew the enterprise was noble, but on the other he saw it could lead to crystal palaces that were good to nobody. -- MarkJ Tacoma, Washington -- http://mail.python.org/mailman/listinfo/python-list
Closures in leu of pointers?
Hi,
I'd like to use closures to set allow a subroutine to set variables in its
caller, in leu of pointers. But I can't get it to work. I have the following
test pgm, but I can't understand its behaviour:
It uses a function p2() from the module modules.closure1b:
def p2 (proc):
proc (dolly)
I thought the following worked like I expected it to:
from modules.closures1b import p2
def p1(msg1):
msg3 = world
print p1: entered: , msg1
def p11(msg2):
print p11: entered: , msg2
print msg1 + msg2 + msg3
print p2 (p11)
p1('hello')
$ python closures1c.py
p1: entered: hello
p11: entered: dolly
hellodollyworld
None
In other words, p1() is passed hello for msg1, world goes to the local msg3
and then p11() is invoked out of a remote module and it can access not only its
own argument (msg2) but also the variables local to p1(): hellodollyworld.
But if I try to set the variable local to p1(), all of a sudden python seems to
forget everything we agreed on.
If I add this line to the script above:
msg3 = goodbye
as follows:
from modules.closures1b import p2
def p1(msg1):
msg3 = world
print p1: entered: , msg1
def p11(msg2):
print p11: entered: , msg2
print msg1 + msg2 + msg3
msg3 = goodbye # - new
print p2 (p11)
p1('hello')
then all of a sudden, I get this:
p1: entered: hello
p11: entered: dolly
Traceback (most recent call last):
File closures1c.py, line 13, in module
p1('hello')
File closures1c.py, line 11, in p1
print p2 (p11)
File /home/mellman/eg/python/modules/closures1b.py, line 2, in p2
proc (dolly)
File closures1c.py, line 9, in p11
print msg1 + msg2 + msg3
UnboundLocalError: local variable 'msg3' referenced before assignment
Huh? msg3 isn't more referenced than it was before!
Can anyone explain this to me?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On 29 Jun 2013 10:38, cts.private.ya...@gmail.com wrote:
Hi,
I'd like to use closures to set allow a subroutine to set variables in
its caller, in leu of pointers. But I can't get it to work. I have the
following test pgm, but I can't understand its behaviour:
It uses a function p2() from the module modules.closure1b:
def p2 (proc):
proc (dolly)
I thought the following worked like I expected it to:
from modules.closures1b import p2
def p1(msg1):
msg3 = world
print p1: entered: , msg1
def p11(msg2):
print p11: entered: , msg2
print msg1 + msg2 + msg3
print p2 (p11)
p1('hello')
$ python closures1c.py
p1: entered: hello
p11: entered: dolly
hellodollyworld
None
In other words, p1() is passed hello for msg1, world goes to the
local msg3 and then p11() is invoked out of a remote module and it can
access not only its own argument (msg2) but also the variables local to
p1(): hellodollyworld.
But if I try to set the variable local to p1(), all of a sudden python
seems to forget everything we agreed on.
If I add this line to the script above:
msg3 = goodbye
as follows:
from modules.closures1b import p2
def p1(msg1):
msg3 = world
print p1: entered: , msg1
def p11(msg2):
print p11: entered: , msg2
print msg1 + msg2 + msg3
msg3 = goodbye # - new
print p2 (p11)
p1('hello')
then all of a sudden, I get this:
p1: entered: hello
p11: entered: dolly
Traceback (most recent call last):
File closures1c.py, line 13, in module
p1('hello')
File closures1c.py, line 11, in p1
print p2 (p11)
File /home/mellman/eg/python/modules/closures1b.py, line 2, in p2
proc (dolly)
File closures1c.py, line 9, in p11
print msg1 + msg2 + msg3
UnboundLocalError: local variable 'msg3' referenced before assignment
Huh? msg3 isn't more referenced than it was before!
Can anyone explain this to me?
The fact that msg3 is assigned to in that scope makes it a local variable.
It doesn't matter if the assignment happens later. Python will treat it as
local, and so won't look for it outside the local scope/closure.
The fix is to declare msg3 as global, I think.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
cts.private.ya...@gmail.com wrote:
I'd like to use closures to set allow a subroutine to set variables in its
caller, in leu of pointers.
leu? Must be a Fench word ;)
But I can't get it to work. I have the
following test pgm, but I can't understand its behaviour:
It uses a function p2() from the module modules.closure1b:
def p2 (proc):
proc (dolly)
I thought the following worked like I expected it to:
from modules.closures1b import p2
def p1(msg1):
msg3 = world
print p1: entered: , msg1
def p11(msg2):
print p11: entered: , msg2
print msg1 + msg2 + msg3
print p2 (p11)
p1('hello')
$ python closures1c.py
p1: entered: hello
p11: entered: dolly
hellodollyworld
None
In other words, p1() is passed hello for msg1, world goes to the local
msg3 and then p11() is invoked out of a remote module and it can access
not only its own argument (msg2) but also the variables local to p1():
hellodollyworld.
But if I try to set the variable local to p1(), all of a sudden python
seems to forget everything we agreed on.
If I add this line to the script above:
msg3 = goodbye
as follows:
from modules.closures1b import p2
def p1(msg1):
msg3 = world
print p1: entered: , msg1
def p11(msg2):
print p11: entered: , msg2
print msg1 + msg2 + msg3
msg3 = goodbye # - new
print p2 (p11)
p1('hello')
then all of a sudden, I get this:
p1: entered: hello
p11: entered: dolly
Traceback (most recent call last):
File closures1c.py, line 13, in module
p1('hello')
File closures1c.py, line 11, in p1
print p2 (p11)
File /home/mellman/eg/python/modules/closures1b.py, line 2, in p2
proc (dolly)
File closures1c.py, line 9, in p11
print msg1 + msg2 + msg3
UnboundLocalError: local variable 'msg3' referenced before assignment
Huh? msg3 isn't more referenced than it was before!
Can anyone explain this to me?
You picked the most obnoxious variable names I can think of, but the actual
problem is simple:
Python statically determines the scope of a variable. If you rebind a name
it becomes a local variable unless you explicitly declare it as global or --
in Python 3 -- as nonlocal. For example:
Wrong:
def outer():
... n = 0
... def inner():
... print(n)
... n += 1
... return inner
...
outer()()
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 4, in inner
UnboundLocalError: local variable 'n' referenced before assignment
With nonlocal declaration (Python 3 only):
def outer():
... n = 0
... def inner():
... nonlocal n
... print(n)
... n += 1
... return inner
...
f = outer()
f()
0
f()
1
f()
2
With a mutable variable as a pseudo-namespace (workaround for Python 2):
def outer():
... n = [0]
... def inner():
... print n[0]
... n[0] += 1
... return inner
...
f = outer()
f()
0
f()
1
--
http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
Well, it would have been French if I had spelled it right - since you force me overcome my laziness, I see I should have spelled it lieu ... Thank you. You reminded me of the (weak) workaround of using arrays and confirmed my suspicion that I although I can read the variable, I won't be able to write to it. I still don't understand why not, though... As for python 3 ... nonlocal? I see I'm not alone in picking obnoxious names ... -- http://mail.python.org/mailman/listinfo/python-list
MeCab UTF-8 Decoding Problem
Hi,
I am trying to use a program called MeCab, which does syntax analysis on
Japanese text. The problem I am having is that it returns a byte string and if
I try to print it, it prints question marks for almost all characters. However,
if I try to use .decide, it throws an error. Here is my code:
#!/usr/bin/python
# -*- coding:utf-8 -*-
import MeCab
tagger = MeCab.Tagger(-Owakati)
text = 'MeCabで遊んでみよう！'
result = tagger.parse(text)
print result
result = result.decode('utf-8')
print result
And here is the output:
MeCab �� �� ��んで�� �� ��う！
Traceback (most recent call last):
File test.py, line 11, in module
result = result.decode('utf-8')
File /usr/lib/python2.7/encodings/utf_8.py, line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 6-7: invalid
continuation byte
--
(program exited with code: 1)
Press return to continue
Also my terminal is able to display Japanese characters properly. For example
print '日本語' works perfectly fine.
Any ideas?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
Alas, one reason it's a weak workaround is that it doesn't work - at least, not how I wish it would: $ cat ptrs x = 34 def p1 (a1): a1[0] += 12 p1 ([x]) print (x) $ python ptrs 34 -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
cts.private.ya...@gmail.com wrote:
As for python 3 ... nonlocal? I see I'm not alone in picking obnoxious
names ...
tous chez...
Alas, one reason it's a weak workaround is that it doesn't work - at
least, not how I wish it would:
$ cat ptrs
x = 34
def p1 (a1):
a1[0] += 12
p1 ([x])
print (x)
$ python ptrs
34
That doesn't work with 'nonlocal' either.
You can compare Python's names with (automatically dereferenced and
garbage-collected) pointers, but there is no way to have a name refer to
another name. The C-like
f(var *value)
{
value = ...
}
is the only way to pass a variable in Python. There is no way to emulate
f(var **value)
{
*value = ...
}
When this came up a few days ago I linked to
http://learntofish.wordpress.com/2012/01/09/call-by-object-reference-call-by-sharing/
but I was actually looking for the classic, so there:
http://python.net/~mwh/hacks/objectthink.html
PS: If you're reading this and love the French language -- I am deeply sorry
for the pain I'm causing you...
--
http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
PS: If you're reading this and love the French language -- I am deeply sorry for the pain I'm causing you... It's obviously a team effort... My French ain't so hot, either. I had to google your tout chez until I ran into the explanation: hallo :) also ich gucke super gerne two and a half men und da wird öfters tout chez (keine ahnung ob es so geschrieben wird) gesagt. ich hab gegooglet aber nichts gefunden. ich habs auch überstzen lassen aber da kommt nur raus alles bei...das wirds ja wohl nicht sein^^ könnte mir also jemand sagen was es genau bedeutet wenn man das sagt? The answer for us TV-challenged non-views: Es heißt: touché -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is the argparse module so inflexible?
On 05:28 Sat 29 Jun , Steven D'Aprano wrote: On Fri, 28 Jun 2013 18:36:37 -0700, Ethan Furman wrote: On 06/27/2013 03:49 PM, Steven D'Aprano wrote: [rant] I think it is lousy design for a framework like argparse to raise a custom ArgumentError in one part of the code, only to catch it elsewhere and call sys.exit. At the very least, that OUGHT TO BE A CONFIG OPTION, and OFF BY DEFAULT. [emphasis added] Libraries should not call sys.exit, or raise SystemExit. Whether to quit or not is not the library's decision to make, that decision belongs to the application layer. Yes, the application could always catch SystemExit, but it shouldn't have to. So a library that is explicitly designed to make command-line scripts easier and friendlier should quit with a traceback? Really? Yes, really. Tracebacks are not that unfriendly, generally speaking. In my experience, the average non-technical person is no more confused and distressed by a traceback extending over thirty lines than they are by a one line error message. As the developer, I should see the tracebacks by default[1]. If I want to suppress or simplify them, then I should take explicit steps to do so, either by catching the exception and calling sys.exit myself, or at least by setting a runtime config option to the library. This also allows me to enable debugging in my app by showing tracebacks, or disable it by hiding them. That should be my decision, not the library. If the library catches exceptions then exits, throwing away potentially useful information, that makes it difficult to debug anything relying on the library. I'm willing to concede that, just maybe, something like argparse could default to catch exceptions and exit ON rather than OFF. [1] There's something in the Zen of Python about that... -- Steven -- Although I got confused at the first time I was using argparse (or optparse which is now obsolte and also has this feature), I see the value when you write scripts. It is mostly annoying when playing with it in a console, but there is a very easy (but partial) fix for that: just subclass argparse.ArgumentParser: import sys class ArgumentParser(argparse.ArgumentParser): def exit(self, status=0, message=None): if message: self._print_message(message, sys.stderr) now the parser will not exit, though there is no ease fix to get the traceback: self.exit() is called in various places sometimes inside a try block. Best regards, Marcin http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: indexerror: list index out of range??
On 06/28/2013 11:35 PM, Titiksha wrote: On Friday, June 28, 2013 8:20:28 PM UTC-5, Titiksha wrote: SNIP double-spaced nonsense m=['631138', '601034', '2834', '2908', '64808'] SNIP more double-spaced nonsense ['LAKEFLD 3227,631138\n', 'NOBLES 3013,601034\n'] Since you're using the arrogant and buggy GoogleGroups, this http://wiki.python.org/moin/GoogleGroupsPython. I see the line,a being correct but print (i) does not show up after 2. and index error comes up. I am too confused now. Please guide. Thanks in advance. Thanks for helping out! Dave you mentioned about false matches in case of string in m is substring of line. How do I manage that issue? Is there any other method I should look into? Suppose one of the items in m were '1234', and suppose one of the lines in the file be 'HARMONY 12,441234913' Your current logic would consider it a match, and I'm assuming that would be a false match. To fix that, you need to parse the line from the file, and separate it into fields, one of which needs to exactly match 1234. You call it a csv file, and if it were, you could just use the csv module. But there's no comma between LAKEFLD and 3227, so the line would be considered to have two fields. If that's correct, then you're golden. Just use csv to get the fields, and compare m[i] == field[1] rather than m[i] in line. What I am looking to do is..I have a list of m which I need to map in the same sequence to the ALL_BUSES_FINAL file and get the entire line which has the string in m.I want to iterate through all the lines in ALL_BUSES_FINAL to match the all strings in m. Any way I can interpret those sentences, it contradicts itself. Could you just post the complete assignment, without paraphrasing? Taking an individual phrase of what you said: same sequence implies you do NOT want to re-open the file multiple times. So move the open outside of the while loop. Add a test and a break after incrementing i, since you'll quit looking once you have a match for all the items, and you'll know that when i reaches the len of m. Hopefully you'll know how to get the single line out of a when you're done, maybe by concatenating field[0] of each line. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: MeCab UTF-8 Decoding Problem
On 2013-06-29, fob...@gmail.com wrote:
Hi,
I am trying to use a program called MeCab, which does syntax analysis on
Japanese text. The problem I am having is that it returns a byte string
and if I try to print it, it prints question marks for almost all
characters. However, if I try to use .decide, it throws an error. Here
is my code:
#!/usr/bin/python
# -*- coding:utf-8 -*-
import MeCab
tagger = MeCab.Tagger(-Owakati)
text = 'MeCab'
result = tagger.parse(text)
print result
result = result.decode('utf-8')
print result
And here is the output:
MeCab ?? ?? ?? ??
Traceback (most recent call last):
File test.py, line 11, in module
result = result.decode('utf-8')
File /usr/lib/python2.7/encodings/utf_8.py, line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 6-7:
invalid continuation byte
--
(program exited with code: 1)
Press return to continue
Find out what the output of tagger.parse is. Your program assumes it is a
bytestring that contains the utf-8 encoded representation of some text,
but it is obvious that this assumption is wrong.
--
Real (i.e. statistical) tennis and snooker player rankings and ratings:
http://www.statsfair.com/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On 06/29/2013 05:44 AM, cts.private.ya...@gmail.com wrote: Alas, one reason it's a weak workaround is that it doesn't work - at least, not how I wish it would: $ cat ptrs x = 34 def p1 (a1): a1[0] += 12 p1 ([x]) print (x) $ python ptrs 34 you'll have to use it more like this (and also changing your names to be a bit more sane): x = [ 34, ] def test_func( out ): out[0] += 12 test_func(x) print (x) -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On 06/29/2013 05:21 AM, cts.private.ya...@gmail.com wrote: Thank you. You reminded me of the (weak) workaround of using arrays and confirmed my suspicion that I although I can read the variable, I won't be able to write to it. I still don't understand why not, though... The real problem here is that you don't understand how python variables work. And in fact, python does not have variables. It has names that bind to objects. If you assign a value to a name, you're not overwriting a variable, you're rebinding a name to a new object in the default scope (unless it's declared global, or nonlocal in python 3, the latter I assume uses the same scope in which it was first declared, but I could be wrong). Since the name is in the local scope, the original name in the caller's scope is still bound to its original object. Furthermore, most primitive objects in python (strings, ints, etc) are immutable, which means they can *never change*. Writing to a variable simply dereferences the old object (which may still be referenced in the caller's scope) and creates a new object and binds it to the name. A list is mutable, which is why it's one solution to emulate a variable. As for python 3 ... nonlocal? I see I'm not alone in picking obnoxious names ... nonlocal at least has meaning. -- http://mail.python.org/mailman/listinfo/python-list
Re: MeCab UTF-8 Decoding Problem
On 06/29/2013 07:29 AM, fob...@gmail.com wrote:
Hi,
Using Python 2.7 on Linux, presumably? It'd be better to be explicit.
I am trying to use a program called MeCab, which does syntax analysis on
Japanese text. The problem I am having is that it returns a byte string and if
I try to print it, it prints question marks for almost all characters. However,
if I try to use .decide, it throws an error. Here is my code:
What do the MeCab docs say the tagger.parse byte string represents?
Maybe it's not text at all. But surely it's not utf-8.
#!/usr/bin/python
# -*- coding:utf-8 -*-
import MeCab
tagger = MeCab.Tagger(-Owakati)
text = 'MeCabで遊んでみよう！'
result = tagger.parse(text)
print result
result = result.decode('utf-8')
print result
And here is the output:
MeCab �� �� ��んで�� �� ��う！
Traceback (most recent call last):
File test.py, line 11, in module
result = result.decode('utf-8')
File /usr/lib/python2.7/encodings/utf_8.py, line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 6-7: invalid
continuation byte
--
(program exited with code: 1)
Press return to continue
Also my terminal is able to display Japanese characters properly. For example
print '日本語' works perfectly fine.
Are your terminal and your text editor using utf-8, or something else?
Can you put your print statement in the source file above, and it'll
also work fine?
Are you actually running it from the terminal, or some GUI? I notice
you get (program exited with code: 1) and Press return to continue.
Neither of those is standard terminal fare on any OS I know of.
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why is the argparse module so inflexible?
In article mailman.3980.1372480662.3114.python-l...@python.org, Terry Reedy tjre...@udel.edu wrote: So a library that behaves like an app is OK? No, Steven is right as a general rule (do not raise SystemExit), but argparse was considered an exception because its purpose is to turn a module into an app. With the responses I have seen here, I agree that this is a bit short-sighted, as inflexible behavior. The tracker issue could use more review and comment. What is the tracker issue number or url? -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is the argparse module so inflexible?
On 2013.06.29 09:12, Roy Smith wrote: What is the tracker issue number or url? http://bugs.python.org/issue9938 -- CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1 -- http://mail.python.org/mailman/listinfo/python-list
Re: indexerror: list index out of range??
On 29/06/2013 14:44, Dave Angel wrote: On 06/28/2013 11:35 PM, Titiksha wrote: Since you're using the arrogant and buggy GoogleGroups, this http://wiki.python.org/moin/GoogleGroupsPython. Please don't make comments like this, you'll upset the Python Mailing List Police. -- Steve is going for the pink ball - and for those of you who are watching in black and white, the pink is next to the green. Snooker commentator 'Whispering' Ted Lowe. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On 29/06/2013 13:26, cts.private.ya...@gmail.com wrote: PS: If you're reading this and love the French language -- I am deeply sorry for the pain I'm causing you... It's obviously a team effort... My French ain't so hot, either. I had to google your tout chez until I ran into the explanation: hallo :) also ich gucke super gerne two and a half men und da wird öfters tout chez (keine ahnung ob es so geschrieben wird) gesagt. ich hab gegooglet aber nichts gefunden. ich habs auch überstzen lassen aber da kommt nur raus alles bei...das wirds ja wohl nicht sein^^ könnte mir also jemand sagen was es genau bedeutet wenn man das sagt? The answer for us TV-challenged non-views: Es heißt: touché Try reading Stephen Clarke's 1000 Years of Annoying the French. Perfect when summing up how good they are are at raising white flags wherever and whenever it suits them. -- Steve is going for the pink ball - and for those of you who are watching in black and white, the pink is next to the green. Snooker commentator 'Whispering' Ted Lowe. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
I love the title. Reminds me of Ivanhoe ... great time travel. -- http://mail.python.org/mailman/listinfo/python-list
Re: MeCab UTF-8 Decoding Problem
On 6/29/2013 10:02 AM, Dave Angel wrote:
On 06/29/2013 07:29 AM, fob...@gmail.com wrote:
Hi,
Using Python 2.7 on Linux, presumably? It'd be better to be explicit.
I am trying to use a program called MeCab, which does syntax analysis
on Japanese text.
It is generally nice to give a link when asking about 3rd party
software. https://code.google.com/p/mecab/
In this case, nearly all the non-boilerplate text is Japanese ;-(.
The problem I am having is that it returns a byte string
and the problem with bytes is that they can have any encoding.
In Python 2 (indicated by your print *statements*), a byte string is
just a string.
and if I try to print it, it prints question marks for almost
all characters. However, if I try to use .decide, it throws an error.
Here is my code:
What do the MeCab docs say the tagger.parse byte string represents?
Maybe it's not text at all. But surely it's not utf-8.
https://mecab.googlecode.com/svn/trunk/mecab/doc/index.html
MeCab: Yet Another Part-of-Speech and Morphological Analyzer
followed by Japanese.
#!/usr/bin/python
# -*- coding:utf-8 -*-
import MeCab
tagger = MeCab.Tagger(-Owakati)
text = 'MeCabで遊んでみよう！'
Parts of this appear in the output, as indicated by spaces.
'MeCabで遊 んで みよ う！'
result = tagger.parse(text)
print result
result = result.decode('utf-8')
print result
And here is the output:
MeCab �� �� ��んで�� �� ��う！
Python normally prints bytes with ascii chars representing either
themselves or other values with hex escapes. This looks more like
unicode sent to a terminal with a limited character set. I would add
print type(result)
to be sure.
Traceback (most recent call last):
File test.py, line 11, in module
result = result.decode('utf-8')
File /usr/lib/python2.7/encodings/utf_8.py, line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 6-7:
invalid continuation byte
--
(program exited with code: 1)
Press return to continue
Also my terminal is able to display Japanese characters properly. For
example print '日本語' works perfectly fine.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: MeCab UTF-8 Decoding Problem
On 6/29/2013 11:32 AM, Terry Reedy wrote: I am trying to use a program called MeCab, which does syntax analysis on Japanese text. It is generally nice to give a link when asking about 3rd party software. https://code.google.com/p/mecab/ In this case, nearly all the non-boilerplate text is Japanese ;-(. My daughter translated the summary paragraph for me. MeCab is an open source morphological analysis open source engine developed through a collaborative unit project between Kyoto University's Informatics Research Department and Nippon Telegraph and Telephone Corporation Communication Science Laboratories. Its fundamental premise is a design which is general-purpose and not reliant on a language, dictionary, or corpus. It uses Conditional Random Fields (CRF) for the estimation of the parameters, and has improved performance over ChaSen, which uses a hidden Markov model. In addition, on average it is faster than ChaSen, Juman, and KAKASI. Incidentally, the creator's favorite food is mekabu (thick leaves of wakame, a kind of edible seaweed, from near the root of the stalk). -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is the argparse module so inflexible?
On 29/06/2013 06:28, Steven D'Aprano wrote: On Fri, 28 Jun 2013 18:36:37 -0700, Ethan Furman wrote: On 06/27/2013 03:49 PM, Steven D'Aprano wrote: [rant] I think it is lousy design for a framework like argparse to raise a custom ArgumentError in one part of the code, only to catch it elsewhere and call sys.exit. At the very least, that OUGHT TO BE A CONFIG OPTION, and OFF BY DEFAULT. [emphasis added] Libraries should not call sys.exit, or raise SystemExit. Whether to quit or not is not the library's decision to make, that decision belongs to the application layer. Yes, the application could always catch SystemExit, but it shouldn't have to. So a library that is explicitly designed to make command-line scripts easier and friendlier should quit with a traceback? Really? Yes, really. [snip] +1 It's the job of argparse to parse the arguments. What should happen if they're invalid is for its caller to decide. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Zelda II sequel - game engine works - GPLv2
There now is a graph connected roomsystem which provides for a master room with elevators and ropes to climb on. A room in a master room can be easily made out of the file maproomcastleX.py. This is about 10 lines of code. On my blog you can see some pictures http://thediaryofelvishhealer.blogspot.be/ This sequel to The adventure of link now has the full engine to provide for aan overworld, castle and town maps with full game support. The link for the game is : http://github.com/zork9/pygame-pyZeldaII Enjoy, Turtle Wizard -- http://mail.python.org/mailman/listinfo/python-list
Re: python adds an extra half space when reading from a string or list
On 29 June 2013 03:07, charles benoit feather.duster.kung...@gmail.com wrote: STUFF 1) You haven't asked a question. 2) You posted your code twice. That makes it look a lot harder and longer than it really is. 3) Give us a *minimal* reproducible test case. I currently just get: %~ python2 /tmp/nd.py Traceback (most recent call last): File /tmp/nd.py, line 12, in module finale_line2=finale_line NameError: name 'finale_line' is not defined This isn't the only problem. In other words, you've given us an unsolvable problem. Try again. -- http://mail.python.org/mailman/listinfo/python-list
Re: MeCab UTF-8 Decoding Problem
On 29/06/2013 12:29, fob...@gmail.com wrote:
Hi,
I am trying to use a program called MeCab, which does syntax analysis on
Japanese text. The problem I am having is that it returns a byte string and if
I try to print it, it prints question marks for almost all characters. However,
if I try to use .decide, it throws an error. Here is my code:
#!/usr/bin/python
# -*- coding:utf-8 -*-
import MeCab
tagger = MeCab.Tagger(-Owakati)
This is a bytestring. Are you sure it shouldn't be a Unicode string
instead, i.e. u'MeCabで遊んでみよう！'?
text = 'MeCabで遊んでみよう！'
result = tagger.parse(text)
print result
result = result.decode('utf-8')
print result
And here is the output:
MeCab �� �� ��んで�� �� ��う！
Traceback (most recent call last):
File test.py, line 11, in module
result = result.decode('utf-8')
File /usr/lib/python2.7/encodings/utf_8.py, line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 6-7: invalid
continuation byte
--
(program exited with code: 1)
Press return to continue
Also my terminal is able to display Japanese characters properly. For example
print '日本語' works perfectly fine.
Any ideas?
--
http://mail.python.org/mailman/listinfo/python-list
Re: MeCab UTF-8 Decoding Problem
On Sat, 29 Jun 2013 04:29:23 -0700, fobos3 wrote:
Hi,
I am trying to use a program called MeCab, which does syntax analysis on
Japanese text. The problem I am having is that it returns a byte string
and if I try to print it, it prints question marks for almost all
characters. However, if I try to use .decide, it throws an error. Here
is my code:
#!/usr/bin/python
# -*- coding:utf-8 -*-
import MeCab
tagger = MeCab.Tagger(-Owakati)
text = 'MeCabで遊んでみよう！'
I see from below you are using Python 2.7.
Here you are using a byte-string rather than Unicode. The actual bytes
that you get *may* be indeterminate. I don't think that Python guarantees
that just because the source file is declared as UTF-8, that *implicit*
encoding into bytes will necessarily use UTF-8.
Even if it does, it is still better to use an explicit Unicode string,
and explicitly encode into bytes using whatever encoding MeCab expects
you to use, say:
text = u'MeCabで遊んでみよう！'.encode('utf-8')
By the way, what makes you think that MeCab expects, and returns, text
encoded using UTF-8?
result = tagger.parse(text)
print result
result = result.decode('utf-8')
print result
And here is the output:
MeCab �� �� ��んで�� �� ��う！
MeCab has returned a bunch of bytes, representing some text in some
encoding. When you print those bytes, your terminal uses whatever its
default encoding is (probably UTF-8, on a Linux system) and tries to make
sense of the bytes, using � for any byte it cannot make sense of. This is
good evidence that MeCab is *not* actually using UTF-8.
And sure enough, when you try to decode it manually:
Traceback (most recent call last):
File test.py, line 11, in module
result = result.decode('utf-8')
File /usr/lib/python2.7/encodings/utf_8.py, line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 6-7:
invalid continuation byte
Assuming that the bytes being returned are *supposed* to be encoded in
UTF-8, it's possible that MeCab is simply buggy and cannot produce proper
UTF-8 encoded byte strings. This wouldn't surprise me -- after all, using
*byte strings* as non-ASCII text strongly suggests that the author
doesn't understand Unicode very well.
But perhaps more likely, MeCab isn't using UTF-8 at all. What does the
documentation say?
A third possibility is that the string you feed to MeCab is simply
mangled beyond recognition due to the way you create it using the
implicit encoding from chars to bytes. Change the line
text = 'MeCab ...'
to use an explicit Unicode string and encode, as above, and maybe the
error will go away.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: python adds an extra half space when reading from a string or list
On 29/06/2013 17:05, Joshua Landau wrote: On 29 June 2013 03:07, charles benoit feather.duster.kung...@gmail.com wrote: STUFF 1) You haven't asked a question. 2) You posted your code twice. That makes it look a lot harder and longer than it really is. 3) Give us a *minimal* reproducible test case. I currently just get: %~ python2 /tmp/nd.py Traceback (most recent call last): File /tmp/nd.py, line 12, in module finale_line2=finale_line NameError: name 'finale_line' is not defined This isn't the only problem. In other words, you've given us an unsolvable problem. Try again. Why this when the approach to Nick the Incompetant Greek has been to roll out the red carpet? -- Steve is going for the pink ball - and for those of you who are watching in black and white, the pink is next to the green. Snooker commentator 'Whispering' Ted Lowe. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
Op 29-06-13 16:02, Michael Torrie schreef: The real problem here is that you don't understand how python variables work. And in fact, python does not have variables. It has names that bind to objects. I don't understand why members of this list keep saying this. Sure the variables in python behave differently than those in C and algol But they behave similarly as those in smalltalk and lisp and I haven't seen anyone claim that smalltalk and lisp don't have variables. We might as well say that C doesn't have variables, it has names pointing to memory locations or value containers or something like that. AFAICS there is no reason why variable wouldn't be appropiate for python names as opposed to C names. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On Saturday, June 29, 2013 10:32:01 PM UTC+5:30, Antoon Pardon wrote: Op 29-06-13 16:02, Michael Torrie schreef: The real problem here is that you don't understand how python variables work. And in fact, python does not have variables. It has names that bind to objects. I don't understand why members of this list keep saying this. Sure the variables in python behave differently than those in C and algol But they behave similarly as those in smalltalk and lisp and I haven't seen anyone claim that smalltalk and lisp don't have variables. We might as well say that C doesn't have variables, it has names pointing to memory locations or value containers or something like that. AFAICS there is no reason why variable wouldn't be appropiate for python names as opposed to C names. Well mathematicians (or to be more precise functional programmers pretending to be mathematicians) claim that any imperative language does not have variables. And recently on this list I saw the exact opposite claim -- functional languages dont have variables. I also remember my statistics teacher dinning it into us -- a random variable is not a variable. So each one varies according to his own notions I guess :-) -- http://mail.python.org/mailman/listinfo/python-list
Confused approach to Pyinstaller
I have a certain GUI program that I built using Python 2.7 and PyQt4. I want to convert it into a standalone windows executable. I went through the docs for Pyinstaller-2.0 and tried several times but I think that I might be on the wrong approach. Here is the structure of my Program. [Resources] [Hunspell] [stylesheets] resources.py design.py main.py The first three are folders containing necessary files for the program to run. The file main.py imports the other two to run properly. What do I do to go towards making the perfect executable? P.S. I have also imported PyPi modules. Will they make a difference? -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On 06/29/2013 11:02 AM, Antoon Pardon wrote: Op 29-06-13 16:02, Michael Torrie schreef: The real problem here is that you don't understand how python variables work. And in fact, python does not have variables. It has names that bind to objects. I don't understand why members of this list keep saying this. Sure the variables in python behave differently than those in C and algol But they behave similarly as those in smalltalk and lisp and I haven't seen anyone claim that smalltalk and lisp don't have variables. We might as well say that C doesn't have variables, it has names pointing to memory locations or value containers or something like that. Sure but a memory location that contains say an int in C *is* a variable, with or without a name. You can change the int stored in that memory address at will, as part of your normal course. Python's basic data types are immutable. At best we could say they are read-only variables. So no, saying Python doesn't have variables is not the same as saying C doesn't have variables but only memory locations. They are different concepts entirely, though on the surface they look similar. AFAICS there is no reason why variable wouldn't be appropiate for python names as opposed to C names. Sure I see your point, but then again, calling them variables is what led to the OP's issue in the first place. So yes they look like variables, and for the most part act like them, except when they don't. Hence the confusion and why I bring up the difference between python's name binding mechanism and how a variable works. It's exactly the concept that was tripping up the OP. -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On 06/29/2013 07:56 AM, Michael Torrie wrote: x = [ 34, ] def test_func( out ): out[0] += 12 test_func(x) print (x) Well, actually print (x[0]) -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
:) Thank you guys for saying what I was biting my tongue about (thanks everybody for the help, BTW!). This python-think stuff was starting to get on my nerves - but then it occurred to me that - although having many powerful features - it has so many weird restrictions that it requires a special way of thinking and problem solving. I have to work with perl's object-orientation stuff again for awhile, in order to see if either has an advantage. -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On Sat, 29 Jun 2013 04:21:46 -0700, cts.private.yahoo wrote: Thank you. You reminded me of the (weak) workaround of using arrays I think you mean lists, rather than arrays. Python does have an array type, but it is much more restricted. If you want an indirect reference to a value, the simplest ways are via a object such as a list, dict or mutable object with named attributes. That's not really a weak workaround. In C you would dereference a pointer, in Python you dereference a list: ptr = obj; value = *ptr; becomes: ptr[0] = obj value = ptr[0] although don't push the analogy too far, Python lists aren't pointers in the C sense. What Python doesn't have -- and it doesn't seem to me that it could have, without support from the interpreter, is a simple way to indirectly refer to another *name*, rather than another object. and confirmed my suspicion that I although I can read the variable, I won't be able to write to it. I still don't understand why not, though... In Python 2, you simply can't because the interpreter doesn't support it. As for python 3 ... nonlocal? I see I'm not alone in picking obnoxious names ... Huh? You have global for global names. Python require declarations for local names, but if it did it would probably use local. What name would you pick to declare names nonlocal other than nonlocal? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On Sat, 29 Jun 2013 19:02:01 +0200, Antoon Pardon wrote: Op 29-06-13 16:02, Michael Torrie schreef: The real problem here is that you don't understand how python variables work. And in fact, python does not have variables. It has names that bind to objects. I don't understand why members of this list keep saying this. Sure the variables in python behave differently than those in C and algol But they behave similarly as those in smalltalk and lisp and I haven't seen anyone claim that smalltalk and lisp don't have variables. We might as well say that C doesn't have variables, it has names pointing to memory locations or value containers or something like that. AFAICS there is no reason why variable wouldn't be appropiate for python names as opposed to C names. You are absolutely correct in principle. But in practice, there are ten bazillion C, Pascal, COBOL, and BASIC programmers who understand the word variable to mean a named memory location, for every Smalltalk or Lisp programmer who understands a variable as a name binding. So it's pure weight of numbers thing. The average Lisp programmer will be completely aware that variable can mean various things, and take care to determine what the word means in Python. She will immediately grok what we mean, even if she thinks that the no variables part is just an affectation (Heh, those wacky Python dudes think they don't have variables!) but at least she'll understand the name binding part. On the other hand, the average C programmer is barely aware that there are other languages at all, let alone that some of them differ from C in semantics as well as syntax. So by emphasising the differences (Python has no variables? It has name bindings?) we increase the likelihood that he'll learn the differences in semantics as well as syntax. So, in a very practical sense, Python has no variables, it has name bindings is completely wrong except in the sense that really matters: Python's variables don't behave identically to C variables. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On 06/29/2013 12:37 PM, cts.private.ya...@gmail.com wrote: :) Thank you guys for saying what I was biting my tongue about (thanks everybody for the help, BTW!). Sometimes it's best to state the actual problem you're trying to solve and see if there's a pythonic solution that fits it rather than to hack a solution transliterated from C. I'm curious as to if you did get something working and what you ended up with. This python-think stuff was starting to get on my nerves - but then it occurred to me that - although having many powerful features - it has so many weird restrictions that it requires a special way of thinking and problem solving. Interesting point of view. Pythonic ways of programming is in my mind the number one appeal of Python. It's quite clean yet practical. Has enough of the intellectual purity of LISP, Smalltalk, and functional languages to be appealing, yet the practicality of a traditional procedural language. In any language, though you have to grasp the data model. Usually the criticisms of Python come from not a failure to do this, either because it's hard to learn at first, or because people dislike learning something different than what they are used to. A while back we had a fairly pleasant gentleman come on the list from a C# background. His frustrations with Python stemmed from wanting it to be like C#, which of course it isn't. He did not have much success and I'm afraid was left with a sour taste of Python, which of course had nothing to do with the language itself. Python certainly has inconsistencies and there are newbie behavioral gotchas. I have to work with perl's object-orientation stuff again for awhile, in order to see if either has an advantage. Your original post mentioned nothing about object-orientation, so I have no idea how you intend to use OO design, but I think you'll find Python's model fairly workable and consistent. -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On Sat, 29 Jun 2013 11:37:55 -0700, cts.private.yahoo wrote: :) Thank you guys for saying what I was biting my tongue about (thanks everybody for the help, BTW!). This python-think stuff was starting to get on my nerves - but then it occurred to me that - although having many powerful features - it has so many weird restrictions that it requires a special way of thinking and problem solving. Er, no, you're confused. Python's restrictions aren't weird, they make absolutely perfect sense once you understand the programming model. Python has a nice, clean semantic model, far cleaner than most other languages I've looked at, which *cannot decide* on what model they wish to present so they end up with a hodge-podge of bits of different models all lumped together and every piece of random syntax you could ever hope (or perhaps fear) to see. If you insist in thinking of Python as Perl with different syntax, then you won't understand why you can't do certain things -- and you'll equally not realise that you CAN do other things that other languages don't support. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On Sat, 29 Jun 2013 18:45:30 +, Steven D'Aprano wrote: Python require declarations for local names, but if it did it would probably use local. Oops, I meant *doesn't* require declarations. Sorry for the error. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On 06/29/2013 12:51 PM, Steven D'Aprano wrote: You are absolutely correct in principle. But in practice, there are ten bazillion C, Pascal, COBOL, and BASIC programmers who understand the word variable to mean a named memory location, for every Smalltalk or Lisp programmer who understands a variable as a name binding. So it's pure weight of numbers thing. The average Lisp programmer will be completely aware that variable can mean various things, and take care to determine what the word means in Python. She will immediately grok what we mean, even if she thinks that the no variables part is just an affectation (Heh, those wacky Python dudes think they don't have variables!) but at least she'll understand the name binding part. On the other hand, the average C programmer is barely aware that there are other languages at all, let alone that some of them differ from C in semantics as well as syntax. So by emphasising the differences (Python has no variables? It has name bindings?) we increase the likelihood that he'll learn the differences in semantics as well as syntax. So, in a very practical sense, Python has no variables, it has name bindings is completely wrong except in the sense that really matters: Python's variables don't behave identically to C variables. Very good points. Thank you. Good tips for how to better explain things next time it comes up. I'll avoid simply saying Python has no variables. -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On Sunday, June 30, 2013 12:21:35 AM UTC+5:30, Steven D'Aprano wrote: On Sat, 29 Jun 2013 19:02:01 +0200, Antoon Pardon wrote: We might as well say that C doesn't have variables, it has names pointing to memory locations or value containers or something like that. AFAICS there is no reason why variable wouldn't be appropiate for python names as opposed to C names. You are absolutely correct in principle. But in practice, there are ten bazillion C, Pascal, COBOL, and BASIC programmers who understand the word variable to mean a named memory location, for every Smalltalk or Lisp programmer who understands a variable as a name binding. So it's pure weight of numbers thing. I note that the 10 bazillion C… programmers take precedence over 10 centuries of mathematics. I wonder if you are familiar with Weizenbaum -- early doyen of AI. Here is a conversation whose first few paras are relevant http://tech.mit.edu/V105/N16/weisen.16n.html On a more technical note... that imperative programming is a bad idea is one of the harder-to-learn lessons for computer scientists http://blog.languager.org/2012/11/imperative-programming-lessons-not.html -- http://mail.python.org/mailman/listinfo/python-list
Unittest fails to import module
I know the answer to this must be trivial but I am stuck... I am starting on a not too complex Python project. Right now the project file structure contains three subdirectories and two files with Python code: code blablabla.py test blablabla_test.py doc (empty for now) blablabla_test.py contains import unittest and import blablabla $PYTHONPATH points at both the code and the test directories. When I run blablabla_test.py it fails to import blablabla.py I have messed around for oven an hour and get nowhere. I have done unittesting like this with success in the past and I have revisited one of those projects and it still works there. The older project has a slightly flatter structure as it lacks a separate code subdirectory: something.py test something_test.py I have temporarily tried this on the new project but to no avail. Any leads? TIA /Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On Sat, 29 Jun 2013 12:35:54 -0600, Michael Torrie wrote: Python's basic data types are immutable. At best we could say they are read-only variables. Python's basic data types are not necessarily immutable. Lists and dicts are not immutable. Being a high-level language, the idea of primitives like int, double, float, etc from C doesn't really apply. A Python dict is not made up from Python ints. Both int and dict are equally basic. More importantly, you are conflating the idea of a variable (a name) and the value of that variable (a value). Whether a variable is a named memory location or a name binding in a namespace, it's still a name. Ints are not names, whether they are low-level C ints or Python int objects. Comparing the immutability of an int object (value) with the ability to write to a name (read-only variable == constant) confuses the value and the name, which is exactly what we're trying to get away from. So no, saying Python doesn't have variables is not the same as saying C doesn't have variables but only memory locations. They are different concepts entirely, though on the surface they look similar. Antoon is suggesting that instead of defining: A variable is a named memory location, like in C and therefore concluding that Python doesn't have variables, we could define: A variable is a name in a namespace bound to a value, like in Lisp and therefore conclude that Python does have variables, but C doesn't. It's not that the two definitions are different concepts entirely, but that they are two subtly different forms of the same concept, a mapping between names and values. If they were entirely different concepts, like a list and an int, you wouldn't have people confusing them. Nobody ever asks why Python doesn't let you sort an int, or take the square of a list... -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On Sat, Jun 29, 2013 at 11:02 AM, Antoon Pardon antoon.par...@rece.vub.ac.be wrote: Op 29-06-13 16:02, Michael Torrie schreef: The real problem here is that you don't understand how python variables work. And in fact, python does not have variables. It has names that bind to objects. I don't understand why members of this list keep saying this. Sure the variables in python behave differently than those in C and algol But they behave similarly as those in smalltalk and lisp and I haven't seen anyone claim that smalltalk and lisp don't have variables. Perhaps because that is the terminology used by the language documentation: http://docs.python.org/3/reference/executionmodel.html#naming-and-binding -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
exactly that. Without wanting to analyze it in too much depth now, I would want a local keyword to allow me to know I was protecting my variables, and a way to specify other scopes, without so much implied scoping in non-intuitive ways... Now everybody is gonna tell me how wrong I am, but you asked what I want, and that's what keeps aggrevating me with python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unittest fails to import module
In article b38pvbfjlv...@mid.individual.net, Martin Schöön martin.sch...@gmail.com wrote: I know the answer to this must be trivial but I am stuck... I am starting on a not too complex Python project. Right now the project file structure contains three subdirectories and two files with Python code: code blablabla.py test blablabla_test.py doc (empty for now) blablabla_test.py contains import unittest and import blablabla $PYTHONPATH points at both the code and the test directories. A couple of generic debugging suggestions. First, are you SURE the path is set to what you think? In your unit test, do: import sys print sys.path and make sure it's what you expect it to be. When I run blablabla_test.py it fails to import blablabla.py Get unittest out of the picture. Run an interactive python and type import blablabla at it. What happens? One trick I like is to strace (aka truss, dtrace, etc on various operating systems) the python process and watch all the open() system calls. See what paths it attempts to open when searching for blablabla. Sometimes that gives you insight into what's going wrong. I have messed around for oven an hour and get nowhere. What temperature was the oven set at? -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On Sat, 29 Jun 2013 12:20:45 -0700, cts.private.yahoo wrote: exactly that. Exactly what? Who are you replying to? Your post has no context. Without wanting to analyze it in too much depth now, I would want a local keyword to allow me to know I was protecting my variables, and a way to specify other scopes, without so much implied scoping in non-intuitive ways... Huh? What language are you programming in? Python doesn't have implied scoping in non-intuitive ways. Python does have a way to specify other scopes: global to enable writing to the global scope, and in Python 3, nonlocal to specify writing to a nonlocal scope. And what on earth does protecting my variables mean? If it means what I think it means, Python gives it to you for free: you cannot overwrite a variable outside of the local scope without declaring it first. What more protection do you want? Now everybody is gonna tell me how wrong I am, but you asked what I want, and that's what keeps aggrevating me with python. If you want language X, you know where to find it. Perhaps you will find it less aggravating to worry more about the concrete problem you want to solve, than the metaproblem of how to program Perl using Python syntax. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Unittest fails to import module
On Sat, 29 Jun 2013 19:13:47 +, Martin Schöön wrote:
$PYTHONPATH points at both the code and the test directories.
When I run blablabla_test.py it fails to import blablabla.py
What error message do you get?
I have messed around for oven an hour and get nowhere. I have done
unittesting like this with success in the past and I have revisited one
of those projects and it still works there.
[...]
Any leads?
The first step is to confirm that your path is setup correctly. At the
very top of blablabla_test, put this code:
import os, sys
print(os.getenv('PYTHONPATH'))
print(sys.path)
What do they say? What should they say?
The second step is to confirm that you can import the blablabla.py
module. From the command line, cd into the code directory and start up a
Python interactive session, then run import blablabla and see what it
does.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
Touchy aren't we ... :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On 2013-06-29 19:19, Steven D'Aprano wrote:
Nobody ever asks why Python doesn't let you sort an int, or take
the square of a list...
just to be ornery, you can sort an int:
i = 314159265
''.join(sorted(str(i)))
'112345569'
And I suppose, depending on how you define it, you can square a list:
lst = list('abcd')
import itertools
list(itertools.product(lst, lst))
[('a', 'a'), ('a', 'b'), ('a', 'c'), ('a', 'd'), ('b', 'a'), ('b',
'b'), ('b', 'c'), ('b', 'd'), ('c', 'a'), ('c', 'b'), ('c', 'c'),
('c', 'd'), ('d', 'a'), ('d', 'b'), ('d', 'c'), ('d', 'd')]
Or, if you want to do it frequently, Python graciously even allows
you to do things like
class MultiList(list):
... def __pow__(self, power):
... return list(itertools.product(*([self] * power)))
...
lst = MultiList(abcd)
lst ** 2
[('a', 'a'), ('a', 'b'), ('a', 'c'), ('a', 'd'), ('b', 'a'), ('b',
'b'), ('b', 'c'), ('b', 'd'), ('c', 'a'), ('c', 'b'), ('c', 'c'),
('c', 'd'), ('d', 'a'), ('d', 'b'), ('d', 'c'), ('d', 'd')]
:-)
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why is the argparse module so inflexible?
On 06/28/2013 10:28 PM, Steven D'Aprano wrote: I'm willing to concede that, just maybe, something like argparse could default to catch exceptions and exit ON rather than OFF. On this we can agree. :) -- ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On Sat, Jun 29, 2013 at 1:33 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sat, 29 Jun 2013 12:20:45 -0700, cts.private.yahoo wrote: Without wanting to analyze it in too much depth now, I would want a local keyword to allow me to know I was protecting my variables, and a way to specify other scopes, without so much implied scoping in non-intuitive ways... Huh? What language are you programming in? Python doesn't have implied scoping in non-intuitive ways. def f(x): def g(y): print(x) x = y Within g, the variable x is implicitly local, which is non-intuitive since without the assignment it would not be. That said, while I think a local keyword would not be unwelcome, I would not want it to be required. Otherwise we end up with the scoping rules of Lua, where everything is global unless explicitly marked as local. -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On 29 June 2013 20:42, Tim Chase t...@thechases.com wrote: On 2013-06-29 19:19, Steven D'Aprano wrote: Nobody ever asks why Python doesn't let you sort an int, or take the square of a list... just to be ornery, you can sort an int: i = 314159265 ''.join(sorted(str(i))) '112345569' To be yet more ornery, you are merely sorting the string representation of an int. You can sort an int, though: [1].sort() You may say No! You are sorting a *list*! However, is it not fair to say that with: [1, 2, 3, 4, 5].sort() you are sorting integers? That is just a common english idiom. Hence, [1].sort() sorts an int. And I suppose, depending on how you define it, you can square a list: From Wikipedia, a square is the result of multiplying a number, or other expression, by itself. In other words, squaring is exponentiation to the power 2. This means that the only logical definitions would be list*list and list**2. However, it can be done! class PowList(list): def __pow__(self, other): pass PowList([1, 2, 3])**2 // Because being a pedant is more fun when you're doing it competitively // -- http://mail.python.org/mailman/listinfo/python-list
Re: python adds an extra half space when reading from a string or list
On 29 June 2013 18:00, Mark Lawrence breamore...@yahoo.co.uk wrote: On 29/06/2013 17:05, Joshua Landau wrote: asks for clarification Why this when the approach to Nick the Incompetant Greek has been to roll out the red carpet? I am my own person, and should not be judged by the actions of others. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Zelda II sequel - game engine works - GPLv2
The game has a homepage now so you can follow the game there, see http://www.zeldadungeon.net/wiki/The_adventure_of_Link_2 There's also lots of screenshots on that page. TW -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On 6/29/2013 3:47 PM, Ian Kelly wrote: On Sat, Jun 29, 2013 at 1:33 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sat, 29 Jun 2013 12:20:45 -0700, cts.private.yahoo wrote: Huh? What language are you programming in? Python doesn't have implied scoping in non-intuitive ways. def f(x): def g(y): print(x) x = y Within g, the variable x is implicitly local, The assignment looks pretty explicit to me ;-|. But to each his own on 'plicitness. which is non-intuitive since without the assignment it would not be. I think the problem people have is this. Python is *not* an interpreted language in the traditional sense: read a line, interpret and execute it. It is compiled, and the compilation of functions is a two pass affair. The first pass classifies all names. The second pass generates code based on the classification of the first pass. This is not part of the grammar, but implied (required) by the semantic description. If, in the general case, the compiler requires two passes to understand a function body, then *so do people*#. This requirement is what trips up people who are either not used to the idea of two-pass compilation or do not cognize that the language requires it. # The alternative for either program or people is a 1-pass + backtracking process where all understandings are kept provisional until the end of the body and revised as required. 2 passes are simpler. That said, writing deceptive but functionin code is usually bad style. Writing code that looks functional but is buggy is worse. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Unittest fails to import module
On 2013-06-29, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
On Sat, 29 Jun 2013 19:13:47 +, Martin Schöön wrote:
$PYTHONPATH points at both the code and the test directories.
When I run blablabla_test.py it fails to import blablabla.py
What error message do you get?
I have messed around for oven an hour and get nowhere. I have done
unittesting like this with success in the past and I have revisited one
of those projects and it still works there.
[...]
Any leads?
The first step is to confirm that your path is setup correctly. At the
very top of blablabla_test, put this code:
import os, sys
print(os.getenv('PYTHONPATH'))
print(sys.path)
Yes, right, I had not managed to make my change to PYTHONPATH stick.
I said the explanation would be trivial, didn't I?
Thanks for the quick replies. I am back in business now.
No, neither English nor Python are native languages of mine but I
enjoy (ab)using both :-)
/Martin
--
http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On Sat, Jun 29, 2013 at 2:53 PM, Terry Reedy tjre...@udel.edu wrote: # The alternative for either program or people is a 1-pass + backtracking process where all understandings are kept provisional until the end of the body and revised as required. 2 passes are simpler. Or simply an explicit declaration of scope at the beginning of the function definition. -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
No, actually, it's okay that it's local by default, after all. TCL's got that capability of explicitly specifying the scope (up n or something like that?). That's okay for tcl, not sure if it would seem so elegant for python. But you can't tell me that the scenarios that I presented in the beginning of this thread are intuitive. I'm going to have a very hard time ever accepting a language that lets me read a variable but when I try to write to it, it suddenly doesn't want to have to do with it anymore ... but hey, like somebody said - everybody's got their own sense of 'plictedness. -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On 06/29/2013 01:19 PM, Steven D'Aprano wrote: Python's basic data types are not necessarily immutable. Lists and dicts are not immutable. Being a high-level language, the idea of primitives like int, double, float, etc from C doesn't really apply. A Python dict is not made up from Python ints. Both int and dict are equally basic. Indeed. Sorry for not being more clear. I was referring primarily to numeric objects and strings. -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On 06/29/2013 01:20 PM, cts.private.ya...@gmail.com wrote: exactly that. Without wanting to analyze it in too much depth now, I would want a local keyword to allow me to know I was protecting my variables, and a way to specify other scopes, without so much implied scoping in non-intuitive ways... The technical thing you are trying to accomplish, is, as far as I know, not easily doable in Python, except if you use a mutable object like a list. Now everybody is gonna tell me how wrong I am, but you asked what I want, and that's what keeps aggrevating me with python. I presume you're answering the question of what is it you're trying to do. Can't be sure. But chances are good. Far be it from me to tell you how wrong you are. I'm still not even sure what you're trying to do ultimately. -- http://mail.python.org/mailman/listinfo/python-list
Rough sketch of a PEP for issue2292
In order to get the ball rolling, and because after hours of futzing I
still can't get the diff to work (yeah, fine, I'm incompetent), I've
started sketching out how a PEP for http://bugs.python.org/issue2292,
Missing *-unpacking generalizations might look.
It's attached if anyone cares to look. You can insult me over it if
you want, but I'd prefer if you liked it :P. I also don't mind
additions to it if you feel you want to waste some time.
If anyone knows how to get the patch (from the bug report) working, or
where to find
http://code.python.org/python/users/twouters/starunpack after
code.python.org was deleted in favour of hg.python.org (which seems
not to have it), that'd be nice too.
Again, this is a sketch. It's incomplete and I'm likely to replace
large parts of it tomorrow. There's also very little justification and, I
think, there are too many code blocks. So it's all liable to change.
PEP: XXX
Title: Additional Unpacking Generalizations
Version: $Revision$
Last-Modified: $Date$
Author: Joshua Landau jos...@landau.ws
Discussions-To: python-id...@python.org
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 29-Jun-2013
Python-Version: 3.4
Post-History: #TODO
Abstract
This PEP proposes extended usages of the ``*`` iterable unpacking operator.
Specifically:
Multiple unpackings::
print(*[1], *[2])
1 2
dict(**{'x': 1}, **{'y': 2})
{'x': 1, 'y': 2}
Unpacking does not prevent further arguments being passed::
print(*[1], 2)
1 2
dict(**{'x': 1}, y=2)
{'x': 1, 'y': 2}
def f(*args, last): pass
Keywords arguments must still follow positional arguments but now must also
follow ``*``-unpackings. The function of a lone ``*`` in function definitions
is unchanged.
Unpacking inside tuples, lists, sets and dictionaries, and comprehensions for
iterators, lists, sets and dictionaries::
*range(4), 4
(0, 1, 2, 3, 4)
[*range(4), 4]
[0, 1, 2, 3, 4]
{*range(4), 4}
{0, 1, 2, 3, 4}
{'x': 1, **{'y': 2}}
{'x': 1, 'y': 2}
ranges = [range(i) for i in range(5)]
[*item for item in ranges]
[0, 0, 1, 0, 1, 2, 0, 1, 2, 3]
Rationale
=
Current usage of the ``*`` iterable unpacking operator features somewhat
arbitrary restrictions.
A limitation of one unpacking per function call makes some function calls more
verbose than necessary; instead of::
function(**arguments, **more_arguments)
one is forced to write::
kwargs = arguments.copy()
kwargs.update(more_arguments)
function(**kwargs)
or, if they know to do so::
from collections import ChainMap
function(**ChainMap(more_arguments, arguments))
This also applies to any circumstance where you would like to unpack positional
arguments followed by another positional argument::
function(*args, arg)
Function definitions are also now more symmetrical with assignment; whereas
previously just::
first, *others, last = iterable
was valid, now so too is::
def f(first, *others, last):
...
f(*iterable)
There are two primary rationale for unpacking inside of containers. Firstly, it
would make sense for::
lst = (1, 2, 3, 4, 5)
first, *others, last = lst
to be the inverse of::
first, others, last = 1, [2, 3, 4], 5
lst = first, *others, last
Secondly, it vastly simplifies dictionary addition such as::
combination = first_dictionary.copy()
combination.update({x: 1, y: 2})
and equivalents, as now you can just write::
combination = {**first_dictionary, x: 1, y: 2}
which is especially important in contexts where expressions are preferred. This
can also help replace ``lst + [item]``.
Specification
=
This isn't my forté, so it will take a bit longer.
Function calls may accept an unbound number of ``*`` and ``**`` unpackings,
which are allowed anywhere that positional and keyword arguments are allowed
respectively. In approximate pseudo-notation:
::
function_call(
[(*args|arg), ]...
[(**kwargs|kwarg=expr), ]...
)
The function ``lambda *args, last: ...`` now does not require ``last`` to be a
keyword only argument, and thus::
def func(*args, *, keyword_only):
...
is valid. Otherwise, function definitions remain unchanged.
Tuples, lists, sets and dictionaries now allow unpacking. Dictionaries require
``**`` unpacking, all the others require ``*`` unpacking. A dictionary's key
remain in a right-to-left priority order, so ``{**{'a': 1}, 'a': 2, **{'a':
3}}`` evaluates to ``{'a': 3}``.
**I am unclear on what the definition for comprehensions should be: should**
``{**d for d in dicts}`` **work as well as** ``{*s for s in sets}`` **par
exemple?**
Backwards-Incompatibility
=
Parts of this change are not backwards-compatible.
- ``function(kwarg=foo, *args)`` is no longer valid syntax; ``function(*args,
kwarg=foo)`` is required instead
- ``lambda *args, last: ...`` no longer
Re: Looking for a name for a deployment framework...
On Wed, Jun 26, 2013 at 9:40 PM, Roy Smith r...@panix.com wrote: For further hack value, require that all pull requests to the project be done entirely in iambic pentameter: for host in hosts: deploy(the_code).remote() For further hack delight, require a patch Submitted for this code restrict itself To five feet, neither more nor less; iambs. But how should all those colons be pronounced? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On Sat, 29 Jun 2013 14:42:58 -0500, Tim Chase wrote: On 2013-06-29 19:19, Steven D'Aprano wrote: Nobody ever asks why Python doesn't let you sort an int, or take the square of a list... just to be ornery, you can sort an int: i = 314159265 ''.join(sorted(str(i))) '112345569' And I suppose, depending on how you define it, you can square a list: Yeah, but my point is that nobody ever *asks* how to do it, because they don't confuse the two concepts. Those who have some need for sorting the digits of an int-as-string work out how to solve the problem without asking. And you'll note I didn't say that nobody confuses an int and a string. That was no accident :-) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On 6/29/2013 5:21 PM, Ian Kelly wrote: On Sat, Jun 29, 2013 at 2:53 PM, Terry Reedy tjre...@udel.edu wrote: # The alternative for either program or people is a 1-pass + backtracking process where all understandings are kept provisional until the end of the body and revised as required. 2 passes are simpler. Or simply an explicit declaration of scope at the beginning of the function definition. One of the reasons I switched to Python was to not have to do that, or hardly ever. For valid code, an new declaration is hardly needed. Parameters are locals. If the first use of another name binds it (and that includes import, class, and def), it is local. If the first use of does not bind it, it had better not be local (because if it is, there well be an exception). If there are branches, each should be consistent with the others. One should only need two readings to understand and fix unbound local errors. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On Sun, Jun 30, 2013 at 2:32 PM, Terry Reedy tjre...@udel.edu wrote: On 6/29/2013 5:21 PM, Ian Kelly wrote: On Sat, Jun 29, 2013 at 2:53 PM, Terry Reedy tjre...@udel.edu wrote: # The alternative for either program or people is a 1-pass + backtracking process where all understandings are kept provisional until the end of the body and revised as required. 2 passes are simpler. Or simply an explicit declaration of scope at the beginning of the function definition. One of the reasons I switched to Python was to not have to do that, or hardly ever. For valid code, an new declaration is hardly needed. Parameters are locals. If the first use of another name binds it (and that includes import, class, and def), it is local. If the first use of does not bind it, it had better not be local (because if it is, there well be an exception). If there are branches, each should be consistent with the others. One should only need two readings to understand and fix unbound local errors. This is strictly a matter of opinion, and one on which mine differs from yours. I think explicit declarations are better than implicit you've assigned to this name local creations; the declarations help to catch typos. Also, I like the consistency of C-style declarations - where-ever you declare something, it's valid from there in, and not out. Without declarations, there's a magical scope boundary at a function definition that's different from the non-boundary at a loop, for instance. But that's just my opinion. and as Teresa says, I'm only one, and possibly I'm wrong. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Closures in leu of pointers?
On Sat, Jun 29, 2013 at 10:32 PM, Terry Reedy tjre...@udel.edu wrote: On 6/29/2013 5:21 PM, Ian Kelly wrote: Or simply an explicit declaration of scope at the beginning of the function definition. One of the reasons I switched to Python was to not have to do that, or hardly ever. For valid code, an new declaration is hardly needed. Parameters are locals. If the first use of another name binds it (and that includes import, class, and def), it is local. If the first use of does not bind it, it had better not be local (because if it is, there well be an exception). If there are branches, each should be consistent with the others. One should only need two readings to understand and fix unbound local errors. In general I agree, although when reading code I would definitely prefer if the locals were declared. On a related note, I think that generator functions should in some way be explicitly marked as such in the declaration, rather than needing to scan the entire function body for a yield statement to determine whether it's a generator or not. -- http://mail.python.org/mailman/listinfo/python-list
[issue16418] argparse with many choices can generate absurdly long usage message
Changes by paul j3 ajipa...@gmail.com: -- nosy: +paul.j3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18322] test_stat nits
Roundup Robot added the comment: New changeset f3f38c84aebc by Antoine Pitrou in branch 'default': Issue #18322: fix some test_stat nits. http://hg.python.org/cpython/rev/f3f38c84aebc -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18322 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18322] test_stat nits
Antoine Pitrou added the comment: Committed with unittest.main(). Thanks for the comments. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18322 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18266] Fix test discovery for test_largefile.py
Serhiy Storchaka added the comment: There is other problem with test_largefile. It not allows running only selected tests. I.e. ./python -m test.regrtest -v -m test_lseek test_largefile Looks as test_largefile was suboptimal converted to unittest. -- nosy: +facundobatista, giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18266 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18326] Not Clear Docs
New submission from icedream91: I think the documents talking about list.sort() in page http://docs.python.org/3/library/stdtypes.html#list.sort is not clear enough. What asterisk means in sort(*, key=None, reverse=None), may be cmp argument from Python 2, or anything else? Or it is a typo? I think document should explain what this asterisk means. Thanks. -- assignee: docs@python components: Documentation messages: 192034 nosy: docs@python, icedream91 priority: normal severity: normal status: open title: Not Clear Docs versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18326] Not Clear Docs
R. David Murray added the comment: It means they are keyword-only arguments. This could be mentioned in the text, with the term 'keyword-only arguments' linked to an appropriate glossary entry (which appears to need to be added). -- keywords: +easy nosy: +r.david.murray stage: - needs patch versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18280] Documentation is too personalized
Antoine Pitrou added the comment: The sockets tutorial deserves a good overhaul :-) -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18280 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14455] plistlib unable to read json and binary plist files
Ronald Oussoren added the comment: Any review would be greatly appreciated. One thing I'm not too happy about is the use of magic numbers in the binary plist support code, but I think that using constants or a dispatch table would not make the code any clearer. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14455 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18237] unittest.assertRaisesRegex(p) example is wrong in docs
Roundup Robot added the comment: New changeset 4a714fea95ef by Terry Jan Reedy in branch '2.7': Issue #18237: Fix assertRaisesRegexp error caought by Jeff Tratner. http://hg.python.org/cpython/rev/4a714fea95ef New changeset b3d19f0494e7 by Terry Jan Reedy in branch '3.3': Issue #18237: Fix assertRaisesRegexp error caought by Jeff Tratner. http://hg.python.org/cpython/rev/b3d19f0494e7 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18237] unittest.assertRaisesRegex(p) example is wrong in docs
Terry J. Reedy added the comment: I went with adding ' after changing '...' to If you think you might ever submit a more substantial patch, and we hope you do, please submit a Contributor Agreement (now optionally electronic). http://www.python.org/psf/contrib/ When processed (a week?), an * will appear after your name. -- resolution: - fixed stage: - committed/rejected status: open - closed type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18244] singledispatch: When virtual-inheriting ABCs at distinct points in MRO, composed MRO is dependent on haystack ordering
Łukasz Langa added the comment: Looks like the priority ordering you mention is not yet documented anywhere. It definitely makes sense but I'd like to take a step back for a moment to consider the following questions: 1. What additional functionality do our users get with this ordering? In other words, what purpose does this new ordering have? Apart from solving the conflict we're discussing, I can't see any. 2. What disadvantages does this ordering bring to the table? I think that simplicity is a feature. This ordering creates additional complexity in the language. Firstly, there is currently no obvious way for users to distinguish between implicit subclassing (via implementation) or subclassing by `abc.register()`. This creates the dangerous situation where backwards incompatibility introduced by switching between those ABC registration mechanism is nearly impossible to debug. Consider an example: version A of a library has a type which only implicitly subclasses an ABC. User code with singledispatch is created that works with the current state of things. Version B of the same library uses `ABC.register(Type)` and suddenly the dispatch changes without any way for the user to see what's going on. A similar example with explicit subclassing and a different form of registration is easier to debug, but not much, really. Secondly, it creates this awkward situation where dispatch for any custom `MutableMapping` can be different from the dispatch for `dict`. Although the latter is a `MutableMapping` only by means of `MutableMapping.register(dict)`, in reality the whole definition of what a mutable mapping is comes from the behaviour found in `dict`. Following your point of view, dict is less of a mutable mapping than a custom type subclassing the ABC explicitly. You're saying the user should respect the choice of its author but it's clearly suboptimal here. I strongly believe I should be able to swap a mutable mapping implementation with any other and get consistent dispatch. Thirdly, while I can't support this with any concrete examples, I have a gut feeling that considering all three ABC subclassing mechanisms to be equally binding will end up as a toolkit with better composability. The priority ordering on the other hand designs `abc.register()` and implicit subclassing as inferior MRO wannabes. Last but not least, the priority ordering will further complicate the implementation of `functools._compose_mro()` and friends. While the complexity of this code is not the reason of my stance on the matter, I think it nicely shows how much the user has to keep in her head to really know what's going on. Especially that we only consider this ordering to be decisive on a single interitance level. 3. Why is the ordering MRO - register - implicit? The reason I'm asking is that the whole existence of `abc.register()` seems to come from the following: * we want types that predate the creation of an ABC to be considered its subclasses; * we can't use implicit subclassing because either the existence of methods in question is not enough (e.g. Mapping versus Sequence); or the methods are added at runtime and don't appear in __dict__. Considering the above, one might argue that the following order is just as well justified: MRO - implicit - register. I'm aware that the decision to put register first is because if the user is unhappy with the dispatch, she can override the ordering by registering types which were implicit before. But, while I can register third-party types, I can't unregister any. In other words, I find this ordering arbitrary. I hope you don't perceive my position as stubborn, I just care enough to insist on this piece of machinery to be clearly defined and as simple as possible (but not simpler, sure). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18042] Provide enum.unique class decorator
Ethan Furman added the comment: Integrated comments. -- Added file: http://bugs.python.org/file30730/unique.stoneleaf.02.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18327] swapped arguments in compatible_for_assignment()?
New submission from Christian Heimes:
Coverity has found something fishy in our code base:
CID 983564 (#1 of 1): Arguments in wrong order
(SWAPPED_ARGUMENTS)swapped_arguments: The positions of arguments newto and
oldto are inconsistent with the positions of the corresponding parameters for
compatible_for_assignment(PyTypeObject *, PyTypeObject *, char *).
Object/typeobject.c:3326
if (compatible_for_assignment(newto, oldto, __class__)) {
Objects/typeobject.c.3265
static int
compatible_for_assignment(PyTypeObject* oldto, PyTypeObject* newto, char* attr)
--
components: Interpreter Core
messages: 192042
nosy: christian.heimes
priority: normal
severity: normal
stage: test needed
status: open
title: swapped arguments in compatible_for_assignment()?
type: behavior
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18327
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18206] license url in site.py should always use X.Y.Z form of version number
Changes by Demian Brecht demianbre...@gmail.com: -- nosy: +dbrecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18206 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17908] Unittest runner needs an option to call gc.collect() after each test
Changes by Demian Brecht demianbre...@gmail.com: -- nosy: +dbrecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17908 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18292] IDLE Improvements: Unit test for AutoExpand.py
Changes by Phil Webster webster.p...@gmail.com: -- nosy: +philwebster ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18292 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17845] Clarify successful build message
Changes by Demian Brecht demianbre...@gmail.com: -- nosy: +dbrecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18328] Use after free in pystate.c
New submission from Christian Heimes: Coverity doesn't like the code in and I think it's right. Can somebody look into the matter and check Python 3.3, too? http://hg.python.org/cpython/file/ac7bc6700ac3/Python/pystate.c#l376 http://hg.python.org/cpython/file/ac7bc6700ac3/Python/pystate.c#l394 10. freed_arg: tstate_delete_common(PyThreadState *) frees tstate. 395tstate_delete_common(tstate); 11. Condition autoInterpreterState, taking true branch CID 1019639 (#1 of 1): Use after free (USE_AFTER_FREE)12. use_after_free: Using freed pointer tstate. 396if (autoInterpreterState PyThread_get_key_value(autoTLSkey) == tstate) 397PyThread_delete_key_value(autoTLSkey); -- components: Interpreter Core messages: 192043 nosy: christian.heimes priority: normal severity: normal stage: test needed status: open title: Use after free in pystate.c type: behavior versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18328 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14455] plistlib unable to read json and binary plist files
Serhiy Storchaka added the comment: I have added comments on Rietveld. I have to apologize for unwitting misleading of d9pouces. Functional version of the patch is enough Pythonic and it looks more clear to me than object-oriented one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14455 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18329] for line in socket.makefile() speed degradation
New submission from Марк Коренберг: Results or running attached program: $ python2.7 qwe.py TCP mode, makefile method. 198807.2 lines per second (189.6 MB/s). Delay is 5.03 seconds TCP mode, fdopen method. 1041666.7 lines per second (993.4 MB/s). Delay is 0.96 seconds UNIX mode, makefile method. 2040816.3 lines per second (1946.3 MB/s). Delay is 0.49 seconds UNIX mode, fdopen method. 1923076.9 lines per second (1834.0 MB/s). Delay is 0.52 seconds $ python3.2 qwe.py TCP mode, makefile method. 275482.1 lines per second (262.7 MB/s). Delay is 3.63 seconds TCP mode, fdopen method. 909090.9 lines per second (867.0 MB/s). Delay is 1.10 seconds UNIX mode, makefile method. 323624.6 lines per second (308.6 MB/s). Delay is 3.09 seconds UNIX mode, fdopen method. 1694915.3 lines per second (1616.4 MB/s). Delay is 0.59 seconds -- 1. in every case, socket.makefile() is MUCH slower than os.fdopen() when used as for line in fileobject 2. compare speeds between python 2.7 and python 3.2 in same operation. Especially, socketpair+makefile 3. Why not to return os.fdopen() for sockets when socket.makefile() called on unix systems? -- components: IO, Library (Lib) files: qwe.py messages: 192044 nosy: mmarkk priority: normal severity: normal status: open title: for line in socket.makefile() speed degradation type: performance versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file30731/qwe.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18329] for line in socket.makefile() speed degradation
Марк Коренберг added the comment: Yes, results are repeatable, and for python 2.7 I have roughly same timings for UNIX socket. Also, I have straced all variants and see that in all 4 cases (and for both python versions) IO is done using 8192 blocks in size, so buffering is not cause of problems. I have linux 3.5.0, Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18329] for line in socket.makefile() speed degradation
Марк Коренберг added the comment: Well, python 3.3 is slightly faster: $ python3.3 qwe.py TCP mode, makefile method. 380228.1 lines per second (362.6 MB/s). Delay is 2.63 seconds TCP mode, fdopen method. 877193.0 lines per second (836.6 MB/s). Delay is 1.14 seconds UNIX mode, makefile method. 469483.6 lines per second (447.7 MB/s). Delay is 2.13 seconds UNIX mode, fdopen method. 1562500.0 lines per second (1490.1 MB/s). Delay is 0.64 seconds But problem still exists -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12716] Reorganize os docs for files/dirs/fds
A.M. Kuchling added the comment: Closing this issue after a week. Mike Hoy: thanks for your patch. -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4199] add shorthand global and nonlocal statements
A.M. Kuchling added the comment: Bumping version to 3.4. I'll send a note to python-dev about this issue. -- versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4199 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18329] for line in socket.makefile() speed degradation
Serhiy Storchaka added the comment: Try to wrap socket.makefile() with io.BufferedReader(). -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18329] for line in socket.makefile() speed degradation
Richard Oudkerk added the comment: I think in Python 3 makefile() returns a TextIOWrapper object by default. To force the use of binary you need to specfiy the mode: fileobj = ss.makefile(mode='rb') -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18330] Fix idlelib.PyShell.build_subprocess_arglist use of __import__
New submission from Terry J. Reedy:
The purpose of the function is to create a command line for the user
subprocess. Most of its body:
'''
# Maybe IDLE is installed and is being accessed via sys.path,
# or maybe it's not installed and the idle.py script is being
# run from the IDLE source directory.
del_exitf = idleConf.GetOption('main', 'General', 'delete-exitfunc',
default=False, type='bool')
if __name__ == 'idlelib.PyShell':
command = __import__('idlelib.run').run.main(%r) % (del_exitf,)
else:
command = __import__('run').main(%r) % (del_exitf,)
return [sys.executable] + w + [-c, command, str(self.port)]
'''
Question: is it really important to avoid binding the run module to 'run' in
the user process? If so, maybe we should use importlib.import_module, as
'direct use of __import__ is entirely discouraged.
The first command looks 'funny' because of the repetition of 'run'. The reason
is that __import__('idlelib.run') returns idlelib, not idlelib.run. Perhaps it
would work to delete .run in the import, or to use importlib.import_module.
The second command incorrectly assumes that if __name__ == '__main__' (the
alternative to 'idlelib.PyShell'), then the directory containing PyShell and
run is the current working directory. This is true if PyShell is run from that
directory, but
F:\Python\dev\py33\PCbuildpython_d -m idlelib.PyShell
F:\Python\dev\py33\PCbuildpython_d ../Lib/idlelib/PyShell.py
both report ImportError: No module named 'run' and open a shell window and
error message box a few seconds later. The shell closes when the messagebox is
dismissed.
It seems to me that the 'else' caters to a non-existent or impossible use case.
PyShell has several 'from idlelib.X import Y' statements. If those work, then
from idlelib import run' must work, and so too must the function equivalent.
--
messages: 192053
nosy: roger.serwy, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix idlelib.PyShell.build_subprocess_arglist use of __import__
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18330
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18329] for line in socket.makefile() speed degradation
Changes by Марк Коренберг socketp...@gmail.com: Removed file: http://bugs.python.org/file30731/qwe.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18329] for line in socket.makefile() speed degradation
Марк Коренберг added the comment: Eliminate unicode conversion for python3, but results still the same $ python2.7 qwe.py TCP mode, makefile method. 211416.5 lines per second (201.6 MB/s). Delay is 4.73 seconds TCP mode, fdopen method. 1041666.7 lines per second (993.4 MB/s). Delay is 0.96 seconds UNIX mode, makefile method. 2040816.3 lines per second (1946.3 MB/s). Delay is 0.49 seconds UNIX mode, fdopen method. 1886792.5 lines per second (1799.4 MB/s). Delay is 0.53 seconds $ python3.2 qwe.py TCP mode, makefile method. 487804.9 lines per second (465.2 MB/s). Delay is 2.05 seconds TCP mode, fdopen method. 900900.9 lines per second (859.2 MB/s). Delay is 1.11 seconds UNIX mode, makefile method. 625000.0 lines per second (596.0 MB/s). Delay is 1.60 seconds UNIX mode, fdopen method. 1492537.3 lines per second (1423.4 MB/s). Delay is 0.67 seconds $ python3.3 qwe.py TCP mode, makefile method. 512820.5 lines per second (489.1 MB/s). Delay is 1.95 seconds TCP mode, fdopen method. 884955.8 lines per second (844.0 MB/s). Delay is 1.13 seconds UNIX mode, makefile method. 680272.1 lines per second (648.8 MB/s). Delay is 1.47 seconds UNIX mode, fdopen method. 1587301.6 lines per second (1513.8 MB/s). Delay is 0.63 seconds Also, io.BufferedReader() is not my case. I understand that intermediate buffer will increase performance. Problem in implementation of socket.makefile(). That is I want to be fixed. -- Added file: http://bugs.python.org/file30732/qwe.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18329] for line in socket.makefile() speed degradation
Марк Коренберг added the comment: Can anyone test in python 3.4 ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18103] Create a GUI test framework for Idle
Roundup Robot added the comment: New changeset c818c215f1a4 by Terry Jan Reedy in branch '3.3': Issue #18103: Update README.txt and test_idle to describe and run gui tests. http://hg.python.org/cpython/rev/c818c215f1a4 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18103 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18103] Create a GUI test framework for Idle
Roundup Robot added the comment: New changeset 0767363a0393 by Terry Jan Reedy in branch '2.7': Issue #18103: Update README.txt and test_idle to describe and run gui tests. http://hg.python.org/cpython/rev/0767363a0393 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18103 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
