Re: jitpy - Library to embed PyPy into CPython
Albert-Jan Roskam schrieb am 06.12.2014 um 21:28: On Fri, Dec 5, 2014 8:54 PM CET Mark Lawrence wrote: For those who haven't heard thought this might be of interest https://github.com/fijal/jitpy Interesting, but it is not clear to me when you would use jitpy instead of pypy. I think this is trying to position PyPy more in the same corner as other JIT compilers for CPython, as opposed to keeping it a completely separate thing which suffers from being not CPython. It's a huge dependency, but so are others. Being able to choose tools at this level is great, so if PyPy becomes yet another way to speed up the critical 5% of a CPython application, that's a good thing. Stefan -- https://mail.python.org/mailman/listinfo/python-list
Help with exscript with Cisco asa
I am trying to login to enable mode on a Cisco ASA with this script. I can’t
seem to get the enable mode to work. Can anyone help. Does anyone know of a
good doc for exscript lib.
Thank you
Ed
from Exscript.util.start import quickstart
from Exscript.util.file import get_hosts_from_file
from Exscript.protocols.drivers import ios
def do_something(job, host, conn):
conn.send(enable\r)
get_password_prompt(self)
print conn.response
#conn.execute('sh run | i ipv6-address-pool')
#print conn.response
hosts = get_hosts_from_file('myhosts.txt','ssh')
quickstart(hosts, do_something,max_threads = 4 )
--
https://mail.python.org/mailman/listinfo/python-list
module import questions and question about pytest and module imports
garage/ |- __init__.py |- cars/ |- __init__.py |- hummer.py tests/ |- test_cars.py at the top of test_cars.py, there is this: from garage.cars import hummer pytest is on this import statement, so i guess it's incorrect. what should it be? if i open a python repl within tests/, how can i say import hummer.py? do i need to do anything to make pytest aware of hummer.py? thanks for the help! -- https://mail.python.org/mailman/listinfo/python-list
Re: Setting default_factory of defaultdict to key
At the beginning of this thread, Ian Kelly said:
Not with defaultdict, but you can subclass dict and provide a
__missing__ method directly
To emphasize, you don't need to subclass defaultdict -- you need only subclass
dict itself:
class MyDict(dict):
def __missing__(self, key):
self[key] = key
return key
md = MyDict()
md[1] = 111
_ = md[2]
_ = md[another key]
## md now looks like this: {1: 111, 2: 2, 'another key': 'another key'}
The defaultdict documentation is confusing on this point. A *long* time ago, I
filed Bug 9536 to improve the doc, but the fix hasn't bubbled to the surface
yet.
--
https://mail.python.org/mailman/listinfo/python-list
Python Iterables struggling using map() built-in
Hello everyone,
I'm currently in the process of self-study journey, so I have some questions
arisen from time to time.
Today I would like to talk about iterables and iterators,(ask for your help
actually ^_^).
Before I'll continue, just wanted to draw your attention to the fact that I
did some RTFM before posting.
Links:
1. map() built-in definitions:
https://docs.python.org/3/library/functions.html#map -for Python 3.X
https://docs.python.org/2.6/library/functions.html#map - for Python 2.6.X
2. Glossary definitions of iterable and iterator:
https://docs.python.org/3/glossary.html?highlight=glossary
3. Iterator Types:
https://docs.python.org/2/library/stdtypes.html#typeiter
4. iter() definition:
https://docs.python.org/2/library/functions.html#iter
5. Some StackOverflow links, related to the topic:
http://stackoverflow.com/questions/13054057/confused-with-python-lists-are-t
hey-or-are-they-not-iterators
http://stackoverflow.com/questions/9884132/understanding-pythons-iterator-it
erable-and-iteration-protocols-what-exact
http://stackoverflow.com/questions/19523563/python-typeerror-int-object-is-n
ot-iterable
http://stackoverflow.com/questions/538346/iterating-over-a-string
6. And of course, re-read couple of times a relevant parts of the
book ('Learning Python by Mark Lutz).
But the questions still persist, maybe because those examples look too
esoteric though.
Another warning: Despite all my attempts to make my questions as short as
possible it still looks huge. My apologies.
The problem:
Here is the book's example:
Consider the following clever alternative coding for this chapter's zip
emulation examples,
adapted from one in Python's manuals at the time I wrote these words:
def myzip(*args):
iters = map(iter, args)
while iters:
res = [next(i) for i in iters]
yield tuple(res)
Because this code uses iter and next, it works on any type of iterable. Note
that there
is no reason to catch the StopIteration raised by the next(it) inside the
comprehension
here when any one of the arguments' iterators is exhausted-allowing it to
pass ends
this generator function and has the same effect that a return statement
would. The
while iters: suffices to loop if at least one argument is passed, and avoids
an infinite
loop otherwise (the list comprehension would always return an empty list).
This code works fine in Python 2.X as is:
list(myzip('abc', 'lmnop'))
[('a', 'l'), ('b', 'm'), ('c', 'n')]
But it falls into an infinite loop and fails in Python 3.X, because the 3.X
map returns a
one-shot iterable object instead of a list as in 2.X. In 3.X, as soon as
we've run the list
comprehension inside the loop once, iters will be exhausted but still True
(and res will
be []) forever. To make this work in 3.X, we need to use the list built-in
function to
create an object that can support multiple iterations:
def myzip(*args):
iters = list(map(iter, args)) # Allow multiple scans
...rest as is...
Run this on your own to trace its operation. The lesson here: wrapping map
calls in
list calls in 3.X is not just for display!
*END OF THE BOOK EXAMPLE
According to the book , in order to get things work properly in Python 3.X,
I should write this code:
def myzip(*args):
iters = list(map(iter, args))
while iters:
res = [next(i) for i in iters]
yield tuple(res)
And all seemed to be clear here, but, when I tried to run this thing:
k= myzip(1, 2, 3, 4)
next(k)
I got this result:
Traceback (most recent call last):
File pyshell#73, line 1, in module
next(k)
File pyshell#65, line 2, in myzip
iters = list(map(iter, args))
TypeError: 'int' object is not iterable
Finding the problem:
I started to investigate further in order to catch the bug:
What I've tried?
1. L = [1, 2, 3, 4]
iter(L) is L
False --- According to the theory it's OK, because list doesn't have
self iterators.
k = iter(L)
print(k)
list_iterator object at 0x03233F90
next(k)
1
print(list(map(iter, L)))
Traceback (most recent call last):
File pyshell#88, line 1, in module
print(list(map(iter, L)))
TypeError: 'int' object is not iterable
2. I went to strings:
S = 'spam'
iter(S) is S
False ---Same about strings
string = iter(S)
string
str_iterator object at 0x02E24F30
next(string)
's'
and so on.
And then just tried this one:
print(list(map(iter, S)))
[str_iterator object at 0x02E24FF0,
str_iterator object at 0x02E24CF0,
str_iterator object at 0x02E24E10,
str_iterator object at 0x02E24DF0] - At this moment Wrecking
Ball song played in my head %)))
k = list(map(iter,S))
next(k[0])
's'
next(k[0])
Traceback (most recent call
Re: Python Iterables struggling using map() built-in
On Sun, Dec 7, 2014 at 3:44 AM, Ivan Evstegneev webmailgro...@gmail.com wrote: (quoting from the book) Because this code uses iter and next, it works on any type of iterable. Note that there is no reason to catch the StopIteration raised by the next(it) inside the comprehension here when any one of the arguments’ iterators is exhausted—allowing it to pass ends this generator function and has the same effect that a return statement would. I'd just like to point out something here that's about to change. In future versions of Python (starting with 3.5 with a governing directive, and always happening in 3.7), it *will* be important to catch the StopIteration. You can read more about it in PEP 479: https://www.python.org/dev/peps/pep-0479/ By the way, your email would have been far better sent as plain text. It's a bit messy here. k= myzip(1, 2, 3, 4) next(k) I got this result: Traceback (most recent call last): File pyshell#73, line 1, in module next(k) File pyshell#65, line 2, in myzip iters = list(map(iter, args)) TypeError: 'int' object is not iterable We'll get back to this later. 1. L = [1, 2, 3, 4] iter(L) is L False --- According to the “theory” it’s OK, because list doesn’t have self iterators. That's because L is a list, not an iterator. A list is iterable, but since you can iterate over it more than once, it returns a separate list_iterator whenever you call iter() on it. S = 'spam' iter(S) is S False ---Same about strings Again, strings are iterable, they are not iterators. L = [1, 2, 3, 4] k = iter(L) That's calling iter on L list(map(iter, L)) That's calling iter on *every element of* L. 2. Why strings are allowed “to become” an iterators(self-iterators)? Maybe because of files(reading from file) ? Because a string is a sequence of characters. You can iterate over a string to work with its characters. Why the infinite loop would be there and why should list() to make it finite? o_0 If you play around with it, you'll see why the infinite loop happens. Actually, even simpler: try calling that zip function with no arguments, and see what happens. I would suggest not trying to rewrite zip(), but develop your own iterator workings, in order to better understand what's going on. In fact, you can completely avoid map(), using only a longhand form of generator expression; and if you do that, you can easily switch in a list comprehension and see exactly what it's doing. But regardless of the above, I suggest reading through the section Explanation of generators, iterators, and StopIteration in PEP 479. It explains some important concepts which are best kept separate in your head, as conflating them will only confuse. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
The preferred way to implement a new transport in asyncio
Hello fellow pythoneers, First some background: I am implementing an XMPP client library in asyncio. XMPP uses (START-)TLS. However, the native SSL support of Python is rather restricted: We cannot hook into the certificate validation process (it is PKI-all-or-nothing) at all, in addition many of the goodies arrive with Python 3.4 only, while asyncio is available in 3.3 already (with tulip). STARTTLS is also not quite supported with asyncio (for which I found a hack, but it is about as unpleasant as number (3) below). So I wondered how feasible a PyOpenSSL based transport would be. From looking into the asyncio selector_events.py code, it should be managealbe to implement a client-side PyOpenSSL based transport (possibly with STARTTLS support). The main question I have is how to interweave this transport with asyncio itself. Is there a preferred process? My approach would have been to provide a coroutine to the user which takes a loop and the arguments neccessary to create a transport (socket/(hostname, port), ssl context, protocol factory, …) and returns the newly created transport. I’m not entirely sure yet how to create the socket though. I have three (all more or less unpleasant) options in mind: 1. Instead of making a simple transport, I make a Protocol/Transport hybrid one would layer on top of the TCP transport provided by asyncio. This is unpleasant because OpenSSL wants direct access to the socket and I expect trouble with that (have not dug into that yet though). 2. Create a Transport using the original create_connection and hard-unwire it from the loop using remove_reader/writer and hostily take over the socket object. This is unpleasant because it depends on things which I would consider internal details. 3. Duplicate the whole code from the original create_connection implementation, minus the unneeded parts. This is unpleasant because of code duplication. (3) seems like the safest approach to me, as it does not rely on any internalities of asyncio, but it is also the most cumbersome. Ideally, there would be a public version of create_connection which returns the socket instead of creating a transport from it. (If there is general agreement on this, we could take this discussion to python-ideas. ) So, does anyone have input on that? best regards, jwi -- https://mail.python.org/mailman/listinfo/python-list
Re: jitpy - Library to embed PyPy into CPython
On Sun, Dec 7, 2014 11:06 AM CET Stefan Behnel wrote: Albert-Jan Roskam schrieb am 06.12.2014 um 21:28: On Fri, Dec 5, 2014 8:54 PM CET Mark Lawrence wrote: For those who haven't heard thought this might be of interest https://github.com/fijal/jitpy Interesting, but it is not clear to me when you would use jitpy instead of pypy. I think this is trying to position PyPy more in the same corner as other JIT compilers for CPython, as opposed to keeping it a completely separate thing which suffers from being not CPython. It's a huge dependency, but so are others. You mean like psyco? Well, if implementation differences between cpython and pypy are a problem, it might be useful. I've only come across a few unimportant ones. Bu then, I never reimplement __del__. http://pypy.readthedocs.org/en/latest/cpython_differences.html Being able to choose tools at this level is great, so if PyPy becomes yet another way to speed up the critical 5% of a CPython application, that's a good thing. Totally agree, provided that 5 % makes a practical difference (wow, it runs 5 ns faster now :-)) -- https://mail.python.org/mailman/listinfo/python-list
how to install paramiko correctly?
My system:win7+python3.4 . I have installed Crypto and Paramiko . C:\Windows\system32pip3.4 install Crypto Requirement already satisfied (use --upgrade to upgrade): Crypto in d:\python34\ lib\site-packages Cleaning up... C:\Windows\system32pip3.4 install Paramiko Requirement already satisfied (use --upgrade to upgrade): Paramiko in d:\python3 4\lib\site-packages Cleaning up... when import paramiko : import paramiko Traceback (most recent call last): File stdin, line 1, in module File D:\Python34\lib\site-packages\paramiko\__init__.py, line 30, in module from paramiko.transport import SecurityOptions, Transport File D:\Python34\lib\site-packages\paramiko\transport.py, line 49, in module from paramiko.dsskey import DSSKey File D:\Python34\lib\site-packages\paramiko\dsskey.py, line 26, in module from Crypto.PublicKey import DSA ImportError: No module named 'Crypto' When i change the F:\Python34\Lib\site-packages\crypto into F:\Python34\Lib\site-packages\Crypto , import paramiko Traceback (most recent call last): File stdin, line 1, in module File F:\Python34\lib\site-packages\paramiko-1.13.0-py3.4.egg\paramiko\__in _.py, line 31, in module File F:\Python34\lib\site-packages\paramiko-1.13.0-py3.4.egg\paramiko\tran rt.py, line 30, in module File F:\Python34\lib\site-packages\paramiko-1.13.0-py3.4.egg\paramiko\util , line 34, in module File F:\Python34\lib\site-packages\paramiko-1.13.0-py3.4.egg\paramiko\comm py, line 129, in module ImportError: cannot import name 'Random' How can i solve the problem? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python, C++ interaction
On 05/12/14 23:17, wesleiram...@gmail.com wrote: m'giu vous êtès nom souris, pseudo nom cha'rs out oiu êtès, i'ret egop c'hâse I have not idea what that means, but I am sure it would be interesting if I knew French (or whatever it is). Sturla -- https://mail.python.org/mailman/listinfo/python-list
Tuple of lists concatenation - function vs comprehension
Hello, When I have worked in Python shell (IDLE) I found this issue: x = ([1, 2], [3, 4], [5, 6]) L = [] for I in x: L.extend(i) L [1,2,3,4,5,6] But when I try to make comprehension using above expression, I get this: x = ([1, 2], [3, 4], [5, 6]) L = [] [L.extend(i) for i in x] [None, None, None] But this works fine within function: def myfunc(): x = ([1, 2], [3, 4], [5, 6]) L = [] [L.extend(i) for i in x] print(L) myfunc() [1, 2, 3, 4, 5, 6] The question is why I'm getting empty list while working with comprehension in interactive console? Thanks for your help. Ivan. -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuple of lists concatenation - function vs comprehension
On 12/07, Ivan Evstegneev wrote: Hello, When I have worked in Python shell (IDLE) I found this issue: x = ([1, 2], [3, 4], [5, 6]) L = [] for I in x: L.extend(i) L [1,2,3,4,5,6] But when I try to make comprehension using above expression, I get this: x = ([1, 2], [3, 4], [5, 6]) L = [] [L.extend(i) for i in x] [None, None, None] Yes. per the doc, list.extend() returns None. But this works fine within function: def myfunc(): x = ([1, 2], [3, 4], [5, 6]) L = [] [L.extend(i) for i in x] print(L) myfunc() [1, 2, 3, 4, 5, 6] This is also so true, as you are print the var 'L'. The question is why I'm getting empty list while working with comprehension in interactive console? You are also getting [None]*3 in comprenhension inside a function. -- Shiyao Ma http://introo.me -- https://mail.python.org/mailman/listinfo/python-list
RE: Tuple of lists concatenation - function vs comprehension
Hi Shiyao, Now I see, that it was kind of dumb question... x = ([1, 2], [3, 4], [5, 6]) L = [] [L.extend(i) for i in x] [None, None, None] BUT when I check L itself I'll see this one L [1,2,3,5,6] Ok. Thanks. -Original Message- From: Shiyao Ma [mailto:i...@introo.me] Sent: Sunday, December 7, 2014 17:18 To: Ivan Evstegneev Cc: python-list@python.org Subject: Re: Tuple of lists concatenation - function vs comprehension On 12/07, Ivan Evstegneev wrote: Hello, When I have worked in Python shell (IDLE) I found this issue: x = ([1, 2], [3, 4], [5, 6]) L = [] for I in x: L.extend(i) L [1,2,3,4,5,6] But when I try to make comprehension using above expression, I get this: x = ([1, 2], [3, 4], [5, 6]) L = [] [L.extend(i) for i in x] [None, None, None] Yes. per the doc, list.extend() returns None. But this works fine within function: def myfunc(): x = ([1, 2], [3, 4], [5, 6]) L = [] [L.extend(i) for i in x] print(L) myfunc() [1, 2, 3, 4, 5, 6] This is also so true, as you are print the var 'L'. The question is why I'm getting empty list while working with comprehension in interactive console? You are also getting [None]*3 in comprenhension inside a function. -- Shiyao Ma http://introo.me -- https://mail.python.org/mailman/listinfo/python-list
RE: Python Iterables struggling using map() built-in
Awesome Ned, Believe it or not, but I was browsing web for the answer about a half an hour ago. Guess what? I found your web page with the explanations you provided there. ))) Finally, I was ready to send this question to you directly, cause I didn't know that you subscribed to this mailing list too. ^_^ But, you was a bit faster. What a surprise. ))) ))) ))) Thanks a lot for your answer. Ivan. -Original Message- From: Python-list [mailto:python-list-bounces+webmailgroups=gmail@python.org] On Behalf Of Ned Batchelder Sent: Sunday, December 7, 2014 17:29 To: python-list@python.org Subject: Re: Python Iterables struggling using map() built-in On 12/6/14 11:44 AM, Ivan Evstegneev wrote: And as I've promised the question section: 1.What actually map() trying to do in Python 3.X? I mean, why is this works fine: L = [1, 2, 3, 4] k = iter(L) next(k) 1 and so on. But not this: list(map(iter, L)) Traceback (most recent call last): File pyshell#88, line 1, in module print(list(map(iter, L))) TypeError: 'int' object is not iterable Let's unpack the code. You are running: map(iter, L) which is equivalent to: map(iter, [1, 2, 3, 4]) which executes: iter(1), iter(2), iter(3), iter(4) If you try iter(1), you get the error you are seeing. Integers are not iterable. What values would it produce? You ask what this is doing in Python 3, but it happens in any Python version, because integers are not iterable. 2.Why strings are allowed to become an iterators(self-iterators)? Maybe because of files(reading from file) ? I mean why, is this possible: print(list(map(iter, S))) [str_iterator object at 0x02E24FF0, str_iterator object at 0x02E24CF0, str_iterator object at 0x02E24E10, str_iterator object at 0x02E24DF0] This is a confusing thing in Python: strings are iterable, they produce a sequence of 1-character strings: list(hello) ['h', 'e', 'l', 'l', 'o'] This isn't because of reading from files. Open files are iterable, they produce a sequence of strings, one for each line in the file. This is why you can do: for line in file: process(line) Many times, it would be more convenient if strings were not iterable, but they are, and you need to keep it in mind when writing general-purpose iteration. 3.The last question Author says: /But it falls into an infinite loop and fails in Python 3.X, because the 3.X map returns a / /one-shot iterable object instead of a list as in 2.X. In 3.X, as soon as we've run the list / /comprehension inside the loop once, iters will be exhausted but still True/. /To make this / /work in 3.X, we need to use the list built-in function to create an object that can support / /multiple iterations. /(Like:Wat?! ^_^)// Why the infinite loop would be there and why should list() to make it finite? o_0 OK, let's go slowly. There are a few foundational concepts to get under our belt. *** CONCEPTS 1. An iterable is an object that you can pass to iter() to get an iterator. 2. An iterator is an object that can provide you with values one after the other, by using next(). next() will either return the next value, or raise a StopIteration exception, indicating that there are no more values. 3. The only operation supported on iterators is next(). You cannot start them over, you cannot ask if there will be more values, you cannot find out how many values there will be, you can't ask what the last value was, etc. By supporting only one operation, they allow the broadest possible set of implementations. 4. You can ask an iterator for an iterator, and it will return itself. That is: iter(some_iterator) is some_iterator. 5. The for NAME in EXPR construct is equivalent to this: expr_iter = iter(EXPR) try: while True: NAME = next(expr_iter) ..DO_SOMETHING.. except StopIteration: pass 6. In Python 2, map() produces a list of values. Lists are iterable. In Python 3, map() produces a map object, which is an iterator. *** PYTHON 2 EXECUTION OK, now, here is the code in question: 1. def myzip(*args): 2. iters = map(iter, args) 3. while iters: 4. res = [next(i) for i in iters] 5. yield tuple(res) Let's cover the Python 2 execution first. At line 2, map produces a list of iterators. Line 3 will loop forever. Nothing ever changes the list. In fact, this is a very confusing part of this code. The code should have said while True here, because it would work exactly the same. At line 4, we loop over our list of iterators, and pull the next value from each one. HERE'S THE IMPORTANT PART: because iters is a list, it is an iterable, and the for loop on this line will make a new list iterator to visit each iterator in turn. Every time this line is executed, every iterator in the list will be next'ed. Now res is a
Nested dictionaries from a list ?
New to Python, so please go easy.
I've a list of users, who have different profiles on different computers. How
to tackle this through lists and dictionaries? Here is the data example. More
interested in learning how to declare this structure and add/delete/extract
values from whatever data structure is proposed.
users = [ 'Tom', 'Dick', 'Harry' ]
{ 'Tom': { 'computerA: 'Profile101'
'computerB: 'Profile102'
'computerC: 'Profile103' }
{ 'Dick': { 'computerA: 'Profile389'
'computerB: 'Profile390' }
{ 'Harry': { 'computerA: 'Profile201'
'computerB: 'Profile202'
'computerC: 'Profile203'
'computerD: 'Profile204' }
Thanks in advance
--
https://mail.python.org/mailman/listinfo/python-list
Re: module import questions and question about pytest and module imports
On 12/05/2014 11:50 PM, sam pendleton wrote: garage/ |- __init__.py |- cars/ |- __init__.py |- hummer.py tests/ |- test_cars.py at the top of test_cars.py, there is this: from garage.cars import hummer pytest is on this import statement, so i guess it's incorrect. No idea what that statement is trying to say. what should it be? If you're going to import something, it either has to be on the sys.path, or in the current directory. Is garage/ on your sys.path? You can examine sys.path by import sys print(sys.path) -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Setting default_factory of defaultdict to key
On 12/05/2014 03:51 PM, John J Posner wrote:
At the beginning of this thread, Ian Kelly said:
Since this clearly is intended to be part of the earlier thread, please
make it so by using reply-list or whatever equivalent your email program
has.
Not with defaultdict, but you can subclass dict and provide a
__missing__ method directly
To emphasize, you don't need to subclass defaultdict -- you need only
subclass dict itself:
class MyDict(dict):
def __missing__(self, key):
self[key] = key
return key
md = MyDict()
md[1] = 111
_ = md[2]
_ = md[another key]
## md now looks like this: {1: 111, 2: 2, 'another key': 'another key'}
The defaultdict documentation is confusing on this point. A *long* time
ago, I filed Bug 9536 to improve the doc, but the fix hasn't bubbled to
the surface yet.
--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Setting default_factory of defaultdict to key
On Dec 07 at 11:31 -0500, Dave Angel wrote: Since this clearly is intended to be part of the earlier thread, please make it so by using reply-list or whatever equivalent your email program has. Kinda OT. But interested what's the difference between reply-list and to. In addition, based on what information a thread is formed? -- Shiyao Ma http://introo.me -- https://mail.python.org/mailman/listinfo/python-list
Re: Nested dictionaries from a list ?
On 12/07/2014 11:18 AM, Wacky wrote:
New to Python, so please go easy.
I've a list of users, who have different profiles on different computers. How
to tackle this through lists and dictionaries? Here is the data example. More
interested in learning how to declare this structure and add/delete/extract
values from whatever data structure is proposed.
users = [ 'Tom', 'Dick', 'Harry' ]
{ 'Tom': { 'computerA: 'Profile101'
'computerB: 'Profile102'
'computerC: 'Profile103' }
{ 'Dick': { 'computerA: 'Profile389'
'computerB: 'Profile390' }
{ 'Harry': { 'computerA: 'Profile201'
'computerB: 'Profile202'
'computerC: 'Profile203'
'computerD: 'Profile204' }
Thanks in advance
I haven't run this through the Python, so please forgive any typos.
Minimal correction, partly to fix missing commas and extra left curlies:
users = [ 'Tom', 'Dick', 'Harry' ]
mess = { 'Tom': { 'computerA: 'Profile101',
'computerB: 'Profile102',
'computerC: 'Profile103' },
'Dick': { 'computerA: 'Profile389',
'computerB: 'Profile390' },
'Harry': { 'computerA: 'Profile201',
'computerB: 'Profile202',
'computerC: 'Profile203',
'computerD: 'Profile204' }
}
And now to get a particular profile, you'd do something like:
mess[Tom][computerA]
Or to get the nth user's profile, use
mess[users[n]][computerC]
Note that making this tolerant of missing keys is much trickier.
If it were myproblem, I'd not try to use triply nested braces, but make
a class for the user, which has methods to look up profiles. Chances are
that you'll soon have other attributes for those users, and you can then
tack them into the same class.
--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list
Different “reply” functions: reply-to-sender, reply-to-list, reply-to-all (was: Setting default_factory of defaultdict to key)
Shiyao Ma i...@introo.me writes: On Dec 07 at 11:31 -0500, Dave Angel wrote: Since this clearly is intended to be part of the earlier thread, please make it so by using reply-list or whatever equivalent your email program has. Kinda OT. But interested what's the difference between reply-list and to. There are multiple “reply” functions for email: * Reply-to-sender: Use this when you intend to reply privately to the individual who sent the message. * Reply-to-list: Use this when you intend to reply, not to the sender privately, but to the public forum to which they sent their message. * Reply-to-all: Use sparingly if at all, when you want to reply explicitly to every single recipient of the sender's message. This last one quickly gets out of control, so should not be used without then inspecting the set of recipients and trimming out those who may not want more messages in the discussion. If your mail client doesn't have all three of these clearly distinct features, lobby the vendor to add the feature, and until they succeed, switch to one which does. URL:https://www.mail-list.com/reply-to-sender-reply-to-list-reply-to-all/ In addition, based on what information a thread is formed? Every message has exactly one header. A message may have, in its header, a field (such as the “In-Reply-To” or “References” field) to indicate which message(s) this one is in response to. By using that field, any mail client can show that relationship among messages forming a discussion thread. -- \ “I find the whole business of religion profoundly interesting. | `\ But it does mystify me that otherwise intelligent people take | _o__)it seriously.” —Douglas Adams | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Setting default_factory of defaultdict to key
On 12/07/2014 11:43 AM, Shiyao Ma wrote: On Dec 07 at 11:31 -0500, Dave Angel wrote: Since this clearly is intended to be part of the earlier thread, please make it so by using reply-list or whatever equivalent your email program has. Kinda OT. But interested what's the difference between reply-list and to. In addition, based on what information a thread is formed? Each email program uses different buttons and/or menu items to enable the user. So I'm using button names from Thunderbird, but most email programs should have equivalent. WHen I use Write, a new message is composed, and I get to fill in the subject line, the to: field, etc. Such a message always starts a new thread. When I use Reply-list, there is a field within the header of the new message that refers to the previous one. That's in addition to the automatic filling in of the subj: line with a Re:, any quoting that may occur, etc. I also could use Reply-All, and trim out the private recipients. But reply-list is easier, and more likely to end up correct. There is a LOT of information in those headers, and I'm not sure just which one is filled in to make threading work. I'm assuming it's the References: field. If you want to see the headers (and the body/bodies), you can use (in Thunderbird) the View-Message Source menu item. For example in the message you just sent, there are 104 lines before it gets to the first par of your actual message body. That's almost 6k of stuff. Anyway, when I display the messages, they're shown in a hierarchical tree. It's hard to imagine reading a newsgroup like this without that, although I did in the early 80's, under MSDOS. I wrote a utility which sorted the messages by subject line, and at least I tended to see related messages together (except that already-read messages were only visible by search, and if somebody changed the subject line, the thread was (for me only) broken. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python, C++ interaction
On 07/12/2014 15:05, Sturla Molden wrote: On 05/12/14 23:17, wesleiram...@gmail.com wrote: m'giu vous êtès nom souris, pseudo nom cha'rs out oiu êtès, i'ret egop c'hâse I have not idea what that means, but I am sure it would be interesting if I knew French (or whatever it is). Please be careful, the guy who was selling forged Hungarian phrase books might now be selling French ones :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Setting default_factory of defaultdict to key
On Dec 7, 2014 9:33 AM, Dave Angel da...@davea.name wrote: On 12/05/2014 03:51 PM, John J Posner wrote: At the beginning of this thread, Ian Kelly said: Since this clearly is intended to be part of the earlier thread, please make it so by using reply-list or whatever equivalent your email program has. FWIW my email client (gmail) correctly included the message into the thread. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Iterables struggling using map() built-in
On Mon, Dec 8, 2014 at 2:29 AM, Ned Batchelder n...@nedbatchelder.com wrote: 3. The only operation supported on iterators is next(). You cannot start them over, you cannot ask if there will be more values, you cannot find out how many values there will be, you can't ask what the last value was, etc. By supporting only one operation, they allow the broadest possible set of implementations. Technically, this is one of only two operations *guaranteed to be* supported on iterators (the other being that `iter(iterator) is iterator`). There are plenty of iterators which do more than that, but all iterators are guaranteed to support next() and nothing more. (For instance, a generator object is an iterator, and it supports a lot more operations.) 5. The for NAME in EXPR construct is equivalent to this: expr_iter = iter(EXPR) try: while True: NAME = next(expr_iter) ..DO_SOMETHING.. except StopIteration: pass Small subtlety: The body of the for block is _not_ guarded by the try/except. It's more like this: expr_iter = iter(EXPR) while True: try: NAME = next(expr_iter) except StopIteration: break ..DO_SOMETHING.. NOTE: THIS EXAMPLE IS HORRIBLE. This code is crazy-confusing, and should never have been used as an example of iteration. It layers at least three iterations on top of each other, making it very difficult to see what is going on. It uses while iters where while True would do exactly the same thing (iters will never be false). There's one way for iters to be false, and that's if you give it no arguments at all. I've only just noticed this now, as I responded earlier with a suggestion to try passing it no args, which won't work because of that (or at least, won't work in Py2; in Py3, iters will indeed never be false, unless you use list() to coalesce the map). This is something which definitely ought to have been given a comment. Or, more usefully, a guarding 'if' before the loop, rather than needlessly checking at every iteration - if you want an infinite loop guarded by a precondition, write it as such so the subsequent reader can see that that's your intention. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Iterables struggling using map() built-in
On Dec 7, 2014 8:31 AM, Ned Batchelder n...@nedbatchelder.com wrote: NOTE: THIS EXAMPLE IS HORRIBLE. This code is crazy-confusing, and should never have been used as an example of iteration. It layers at least three iterations on top of each other, making it very difficult to see what is going on. It uses while iters where while True would do exactly the same thing (iters will never be false). That's not quite correct; the while iters actually guards against the case where the passed args are empty. With no sub-iterators, no StopIteration would ever be raised, and the result would be an infinite generator of empty tuples. The while iters makes it return immediately instead. So it seems this example is even more confusing than you thought. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Iterables struggling using map() built-in
On Mon, Dec 8, 2014 at 5:27 AM, Ian Kelly ian.g.ke...@gmail.com wrote: On Dec 7, 2014 8:31 AM, Ned Batchelder n...@nedbatchelder.com wrote: NOTE: THIS EXAMPLE IS HORRIBLE. This code is crazy-confusing, and should never have been used as an example of iteration. It layers at least three iterations on top of each other, making it very difficult to see what is going on. It uses while iters where while True would do exactly the same thing (iters will never be false). That's not quite correct; the while iters actually guards against the case where the passed args are empty. With no sub-iterators, no StopIteration would ever be raised, and the result would be an infinite generator of empty tuples. The while iters makes it return immediately instead. So it seems this example is even more confusing than you thought. I'm actually glad PEP 479 will break this kind of code. Gives a good excuse for rewriting it to be more readable. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Setting default_factory of defaultdict to key
On 12/5/2014 3:51 PM, John J Posner wrote: The defaultdict documentation is confusing on this point. A *long* time ago, I filed Bug 9536 to improve the doc, but the fix hasn't bubbled to the surface yet. Untrue. Your patch 'bubbled to the surface' and got provisionally rejected in 5 hours and 7 minutes. As it is, your patch is not acceptable. I will say more on the issue. http://bugs.python.org/issue9536 -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuple of lists concatenation - function vs comprehension
On 12/7/2014 10:28 AM, Ivan Evstegneev wrote: Hi Shiyao, Now I see, that it was kind of dumb question... x = ([1, 2], [3, 4], [5, 6]) L = [] [L.extend(i) for i in x] [None, None, None] Using a list comprehension for the expression side-effect, when you do not actually want the list produced by the comprehension, is considered bad style by many. There is nothing wrong with explicit loops. BUT when I check L itself I'll see this one L [1,2,3,5,6] -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
ANN: A new version (0.3.7) of python-gnupg has been released.
A new version of the Python module which wraps GnuPG has been
released.
What Changed?
=
This is an enhancement and bug-fix release, but the bug-fixes
include some security improvements, so all users are encouraged
to upgrade. See the project website [1] for more information.
Brief summary:
* Added an 'output' keyword parameter to the 'sign' and
'sign_file' methods, to allow writing the signature to a file.
* Allowed specifying 'True' for the 'sign' keyword parameter,
which allows use of the default key for signing and avoids
having to specify a key id when it's desired to use the default.
* Used a uniform approach with subprocess on Windows and POSIX:
shell=True is not used on either.
* When signing/verifying, the status is updated to reflect any
expired or revoked keys or signatures.
* Handled 'NOTATION_NAME' and 'NOTATION_DATA' during verification.
* Fixed #1, #16, #18, #20: Quoting approach changed, since now
shell=False.
* Fixed #14: Handled 'NEED_PASSPHRASE_PIN' message.
* Fixed #8: Added a scan_keys method to allow scanning of keys
without the need to import into a keyring.
* Fixed #5: Added '0x' prefix when searching for keys.
* Fixed #4: Handled 'PROGRESS' message during encryption.
* Fixed #3: Changed default encoding to Latin-1.
* Fixed #2: Raised ValueError if no recipients were specified
for an asymmetric encryption request.
* Handled 'UNEXPECTED' message during verification.
* Replaced old range(len(X)) idiom with enumerate().
* Refactored ``ListKeys`` / ``SearchKeys`` classes to maximise
use of common functions.
* Fixed GC94: Added ``export-minimal`` and ``armor`` options
when exporting keys. This addition was inadvertently left out
of 0.3.6.
This release [2] has been signed with my code signing key:
Vinay Sajip (CODE SIGNING KEY) vinay_sa...@yahoo.co.uk
Fingerprint: CA74 9061 914E AC13 8E66 EADB 9147 B477 339A 9B86
What Does It Do?
The gnupg module allows Python programs to make use of the
functionality provided by the Gnu Privacy Guard (abbreviated GPG or
GnuPG). Using this module, Python programs can encrypt and decrypt
data, digitally sign documents and verify digital signatures, manage
(generate, list and delete) encryption keys, using proven Public Key
Infrastructure (PKI) encryption technology based on OpenPGP.
This module is expected to be used with Python versions = 2.4, as it
makes use of the subprocess module which appeared in that version of
Python. This module is a newer version derived from earlier work by
Andrew Kuchling, Richard Jones and Steve Traugott.
A test suite using unittest is included with the source distribution.
Simple usage:
import gnupg
gpg = gnupg.GPG(gnupghome='/path/to/keyring/directory')
gpg.list_keys()
[{
...
'fingerprint': 'F819EE7705497D73E3CCEE65197D5DAC68F1AAB2',
'keyid': '197D5DAC68F1AAB2',
'length': '1024',
'type': 'pub',
'uids': ['', 'Gary Gross (A test user) gary.gr... at gamma.com']},
{
...
'fingerprint': '37F24DD4B918CC264D4F31D60C5FEFA7A921FC4A',
'keyid': '0C5FEFA7A921FC4A',
'length': '1024',
...
'uids': ['', 'Danny Davis (A test user) danny.da... at delta.com']}]
encrypted = gpg.encrypt(Hello, world!, ['0C5FEFA7A921FC4A'])
str(encrypted)
'-BEGIN PGP MESSAGE-\nVersion: GnuPG v1.4.9 (GNU/Linux)\n
\nhQIOA/6NHMDTXUwcEAf
...
-END PGP MESSAGE-\n'
decrypted = gpg.decrypt(str(encrypted), passphrase='secret')
str(decrypted)
'Hello, world!'
signed = gpg.sign(Goodbye, world!, passphrase='secret')
verified = gpg.verify(str(signed))
print Verified if verified else Not verified
'Verified'
As always, your feedback is most welcome (especially bug reports [3],
patches and suggestions for improvement, or any other points via the
mailing list/discussion group [4]).
Enjoy!
Cheers
Vinay Sajip
Red Dove Consultants Ltd.
[1] https://bitbucket.org/vinay.sajip/python-gnupg
[2] https://pypi.python.org/pypi/python-gnupg/0.3.7
[3] https://bitbucket.org/vinay.sajip/python-gnupg/issues
[4] https://groups.google.com/forum/#!forum/python-gnupg
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Iterables struggling using map() built-in
Chris Angelico wrote: On Mon, Dec 8, 2014 at 5:27 AM, Ian Kelly ian.g.ke...@gmail.com wrote: On Dec 7, 2014 8:31 AM, Ned Batchelder n...@nedbatchelder.com wrote: NOTE: THIS EXAMPLE IS HORRIBLE. This code is crazy-confusing, and should never have been used as an example of iteration. It layers at least three iterations on top of each other, making it very difficult to see what is going on. It uses while iters where while True would do exactly the same thing (iters will never be false). That's not quite correct; the while iters actually guards against the case where the passed args are empty. With no sub-iterators, no StopIteration would ever be raised, and the result would be an infinite generator of empty tuples. The while iters makes it return immediately instead. So it seems this example is even more confusing than you thought. I'm actually glad PEP 479 will break this kind of code. Gives a good excuse for rewriting it to be more readable. What kind of code is that? Short, simple, Pythonic and elegant? :-) Here's the code again, with indentation fixed: def myzip(*args): iters = map(iter, args) while iters: res = [next(i) for i in iters] yield tuple(res) That is *beautiful code*. It's written for Python 2, where map returns a list, so the while iters line is morally equivalent to: while iters != [] and True It would be even more beautiful if we get rid of the unnecessary temporary variable: def myzip(*args): iters = map(iter, args) while iters: yield tuple([next(i) for i in iters]) I think this function makes a good test to separate the masters from the apprentices. No offence intended to Ned, who is a master, anyone can have a bad day or a blind spot. If you can read this function and instantly tell how it works, that it is bug-free and duplicates the behaviour of the built-in zip(), you're probably Raymond Hettinger. If you can tell what it does but you have to think about it for a minute or two before you understand why it works, you can call yourself a Python master. If you have to sit down with the interactive interpreter and experiment for a bit to understand it, you're doing pretty well. I do not believe that good code must be obviously right. It's okay for code to be subtly right. Either is better than complicated code which contains no obvious bugs. How would we re-write this to work in the future Python 3.7? Unless I have missed something, I think we could write it like this: def myzip37(*args): iters = list(map(iter, args)) while iters: try: yield tuple([next(i) for i in iters]) except StopIteration: return which I guess is not too horrible. If Python had never supported the current behaviour, I'd probably be happy with this. But having seen how elegant generators *can* be, the post-PEP 479 version will always look bloated and clumsy to me, like Garfield next to a cheetah. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Nested dictionaries from a list ?
On Sun, 07 Dec 2014 08:18:03 -0800, Wacky wrote:
New to Python, so please go easy.
I've a list of users, who have different profiles .
How are you getting on with this assignment / homework?
I have a solution I could post, but I thought I'd wait to see what your
solution was first.
Here's a hint though, I defined the following functions to work on my
profiles data:
def is_user(user):
def is_machine(machine):
def is_user_of_machine(user, machine):
def is_machine_of_user(user, machine):
def query_machines_of_user(user):
def query_machines():
def query_users_of_machine(machine):
def query_users():
def add_profile(user, machine, profile):
def get_profile(user, machine):
def remove_profile(user, machine):
def remove_user(user):
After defining the functions, I was able to add the following code:
add_profile('Tom', 'computerA', 'Profile101')
add_profile('Tom', 'computerB', 'Profile102')
add_profile('Tom', 'computerC', 'Profile103')
add_profile('Dick', 'computerA', 'Profile389')
add_profile('Dick', 'computerB', 'Profile390')
add_profile('Harry', 'computerA', 'Profile201')
add_profile('Harry', 'computerB', 'Profile202')
add_profile('Harry', 'computerC', 'Profile203')
add_profile('Harry', 'computerD', 'Profile204')
print 'The users are:', query_users()
print 'The machines are:', query_machines()
print 'Users of computerC are:', query_users_of_machine('computerC')
print 'Harry\'s profile on computerB is:', get_profile('Harry',
'computerB')
print 'Tom uses the machines:', query_machines_of_user('Tom')
which generated the following output:
The users are: ['Harry', 'Dick', 'Tom']
The machines are: ['computerA', 'computerB', 'computerC', 'computerD']
Users of computerC are: ['Harry', 'Tom']
Harry's profile on computerB is: Profile202
Tom uses the machines: ['computerA', 'computerB', 'computerC']
Then I added functions to return all of a user's machines and profiles,
and all of a machine's users and profiles.
def query_machine_profiles(user):
def query_user_profiles(machine):
So I could add things like:
print 'The user profiles on computerB are:', query_user_profiles
('computerB')
and get the result:
The user profiles on computerB are: {'Tom': 'Profile102', 'Dick':
'Profile390', 'Harry': 'Profile202'}
By the way, my longest function definition used 7 lines of code, these
are all fairly simple functions, and no list comprehensions.
--
Denis McMahon, denismfmcma...@gmail.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Iterables struggling using map() built-in
On Mon, Dec 8, 2014 at 10:33 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: How would we re-write this to work in the future Python 3.7? Unless I have missed something, I think we could write it like this: def myzip37(*args): iters = list(map(iter, args)) while iters: try: yield tuple([next(i) for i in iters]) except StopIteration: return which I guess is not too horrible. It's not horrible, and there are other ways it could be written too, which also aren't horrible. Yes, it's not quite as short as the other version; but more importantly, it's explicit about how StopIteration affects it. It's clear that this exception, if raised by _any_ of the iterators (even after consuming values from some of them, perhaps), will silently terminate the generator. The current behaviour favours a handful of cases like this, although personally I think the termination of zip() is simply this is what happens if we have no code here, so let's document it rather than being something inherently ideal; the new behaviour favours the debugging of many obscure cases and some less-obscure ones as well. Most importantly, if you run the old version of myzip on Python 3.7, you'll get an immediate and noisy RuntimeError when it terminates, and you'll know exactly where to go fix stuff; if you run a buggy generator on Python 3.4, you simply see no more results, without any explanation of why. I'd rather debug the RuntimeError that can be easily and trivially fixed in 99% of cases. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Nested dictionaries from a list ?
On Sun, 07 Dec 2014 12:01:26 -0500, Dave Angel wrote:
On 12/07/2014 11:18 AM, Wacky wrote:
I've a list of users
I haven't run this through the Python, so please forgive any typos.
users = [
mess = {
users is redundant, as it's mess.keys()
maintaining a separate list of users and having the users as the keys in
mess suggests redundancy, and the potential for errors if the two data
items get out of synch. Better imo to just have the data in one place.
--
Denis McMahon, denismfmcma...@gmail.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python Iterables struggling using map() built-in
Chris Angelico wrote: I'm actually glad PEP 479 will break this kind of code. Gives a good excuse for rewriting it to be more readable. Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: What kind of code is that? Short, simple, Pythonic and elegant? :-) Here's the code again, with indentation fixed: def myzip(*args): iters = map(iter, args) while iters: res = [next(i) for i in iters] yield tuple(res) Ugh. When I see while foo, my brain says, OK, you're about to see a loop which is controlled by the value of foo being changed inside the loop. That's not at all what's happening here, so my brain runs into a wall. Next problem, what the heck is res? We're not back in the punch-card days. We don't have to abbreviate variable names to save columns. Variable names are supposed to describe what they hold, and thus help you understand the code. I have no idea what res is supposed to be. Residue? Result? Rest_of_items? Response? None of these make much sense here, so I'm just left befuddled. It would be even more beautiful if we get rid of the unnecessary temporary variable: def myzip(*args): iters = map(iter, args) while iters: yield tuple([next(i) for i in iters]) Well, that's one way to solve the mystery of what res means, but it doesn't actually make it easier to understand. I think this function makes a good test to separate the masters from the apprentices. The goal of good code is NOT to separate the masters from the apprentices. The goal of good code is to be correct and easy to understand by the next guy who comes along to maintain it. If you can read this function and instantly tell how it works, that it is bug-free and duplicates the behaviour of the built-in zip(), you're probably Raymond Hettinger. If you can tell what it does but you have to think about it for a minute or two before you understand why it works, you can call yourself a Python master. If you have to sit down with the interactive interpreter and experiment for a bit to understand it, you're doing pretty well. That pretty much is the point I'm trying to make. If the code is so complicated that masters can only understand it after a couple of minutes of thought, and those of us who are just doing pretty well need to sit down and puzzle it out in the REPL, then it's too complicated for most people to understand. KISS beats elegant. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Iterables struggling using map() built-in
In article mailman.16689.1417996247.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Mon, Dec 8, 2014 at 10:33 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: How would we re-write this to work in the future Python 3.7? Unless I have missed something, I think we could write it like this: def myzip37(*args): iters = list(map(iter, args)) while iters: try: yield tuple([next(i) for i in iters]) except StopIteration: return I'm still not liking this use of while. Yes, of course, it handles the special case of no arguments, but I'd be in-your-face about that (not tested): def myzip37(*args): iters = list(map(iter, args)) if not iters: return None while True: try: yield tuple([next(i) for i in iters]) except StopIteration: return This makes it really obvious that there's something going on inside the loop other than exhausting the control variable to cause it to exit. Although, to be honest, I'm wondering if this is more straight-forward (also not tested): def myzip37(*args): if not args: return iters = list(map(iter, args)) while True: try: yield tuple(map(next, iters)) except StopIteration: return -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Iterables struggling using map() built-in
On Mon, Dec 8, 2014 at 11:12 AM, Roy Smith r...@panix.com wrote: Ugh. When I see while foo, my brain says, OK, you're about to see a loop which is controlled by the value of foo being changed inside the loop. That's not at all what's happening here, so my brain runs into a wall. I agree, with the caveat that this kind of thing makes a fine infinite loop: while No exception raised: # do stuff that can raise an exception while Playing more games: play_game() if not still_playing: break reset_game_board() Nobody expects a string literal to actually become false inside the loop. With a local name, yes, I would expect it to at least have a chance of becoming false. Next problem, what the heck is res? We're not back in the punch-card days. We don't have to abbreviate variable names to save columns. Variable names are supposed to describe what they hold, and thus help you understand the code. I have no idea what res is supposed to be. Residue? Result? Rest_of_items? Response? None of these make much sense here, so I'm just left befuddled. I take it as result, which makes plenty of sense to me. It's the thing that's about to be yielded. Given that there's not much else you can say in a meta-function like zip(), I have no problem with that. Here's a slightly different example: def mark_last(it): it = iter(it) lastres = sentinel = object() while more values coming: res = next(it, sentinel) if lastres is not sentinel: yield (lastres, res is sentinel) if res is sentinel: return lastres = res Use of res for result and lastres to mean res as of the previous iteration of the loop seems fine to me. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Iterables struggling using map() built-in
On Mon, Dec 8, 2014 at 11:27 AM, Roy Smith r...@panix.com wrote: Although, to be honest, I'm wondering if this is more straight-forward (also not tested): def myzip37(*args): if not args: return iters = list(map(iter, args)) Yes, I prefer this too. It's explicit and clear that passing no arguments will yield no values. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Iterables struggling using map() built-in
On 12/7/2014 7:12 PM, Roy Smith wrote: Chris Angelico wrote: I'm actually glad PEP 479 will break this kind of code. Gives a good excuse for rewriting it to be more readable. Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: What kind of code is that? Short, simple, Pythonic and elegant? :-) Here's the code again, with indentation fixed: def myzip(*args): iters = map(iter, args) while iters: res = [next(i) for i in iters] yield tuple(res) Ugh. When I see while foo, my brain says, OK, you're about to see a loop which is controlled by the value of foo being changed inside the loop. That's not at all what's happening here, so my brain runs into a wall. I agree. Too tricky. The code should have been def myzip(*args): if args: iters = map(iter, args) while True: res = [next(i) for i in iters] yield tuple(res) However, this 'beautiful' code has a trap. If one gets rid of the seemingly unneeded temporary list res by telescoping the last two lines into a bit too much into yield tuple(next(i) for i in iters) we now have an infinite generator, because tuple() swallows the StopIteration raised as a side-effect of next calls. def myzip(*args): if args: iters = map(iter, args) while True: try: result = [next(i) for i in iters] except StopIteration return yield tuple(res) makes the side-effect dependence of stopping clearer. Putting yield tuple([next(i) for i in iters]) in the try would also work. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Iterables struggling using map() built-in
In article mailman.16690.1417998873.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: Next problem, what the heck is res? We're not back in the punch-card days. We don't have to abbreviate variable names to save columns. Variable names are supposed to describe what they hold, and thus help you understand the code. I have no idea what res is supposed to be. Residue? Result? Rest_of_items? Response? None of these make much sense here, so I'm just left befuddled. I take it as result, which makes plenty of sense to me. OK, so spell it out. Three more keystrokes (well, plus another three when you use it on the next line). And one of them is a vowel; they don't even cost much. The next guy who has to read your code will thank you for it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Iterables struggling using map() built-in
On Mon, Dec 8, 2014 at 11:45 AM, Roy Smith r...@panix.com wrote: I take it as result, which makes plenty of sense to me. OK, so spell it out. Three more keystrokes (well, plus another three when you use it on the next line). And one of them is a vowel; they don't even cost much. The next guy who has to read your code will thank you for it. Maybe. Personally, I don't mind the odd abbreviation; they keep the code small enough to eyeball, rather than spelling everything out everywhere. Using cur (or curr) for current, next for next, prev for previous, as prefixes to a short word saying *what* they're the current/next/previous of, is sufficiently obvious IMO to justify the repeated use of the abbreviation. Why does Python have int and str rather than integer and string? Or, worse, arbitrary_precision_integer and unicode_codepoint_string? Common words get shortened - it's a legit form of Huffman compression. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Iterables struggling using map() built-in
On 12/7/14 7:12 PM, Roy Smith wrote: Chris Angelico wrote: I'm actually glad PEP 479 will break this kind of code. Gives a good excuse for rewriting it to be more readable. Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: What kind of code is that? Short, simple, Pythonic and elegant? :-) Here's the code again, with indentation fixed: def myzip(*args): iters = map(iter, args) while iters: res = [next(i) for i in iters] yield tuple(res) Ugh. When I see while foo, my brain says, OK, you're about to see a loop which is controlled by the value of foo being changed inside the loop. That's not at all what's happening here, so my brain runs into a wall. Next problem, what the heck is res? We're not back in the punch-card days. We don't have to abbreviate variable names to save columns. Variable names are supposed to describe what they hold, and thus help you understand the code. I have no idea what res is supposed to be. Residue? Result? Rest_of_items? Response? None of these make much sense here, so I'm just left befuddled. It would be even more beautiful if we get rid of the unnecessary temporary variable: def myzip(*args): iters = map(iter, args) while iters: yield tuple([next(i) for i in iters]) Well, that's one way to solve the mystery of what res means, but it doesn't actually make it easier to understand. I think this function makes a good test to separate the masters from the apprentices. The goal of good code is NOT to separate the masters from the apprentices. The goal of good code is to be correct and easy to understand by the next guy who comes along to maintain it. If you can read this function and instantly tell how it works, that it is bug-free and duplicates the behaviour of the built-in zip(), you're probably Raymond Hettinger. If you can tell what it does but you have to think about it for a minute or two before you understand why it works, you can call yourself a Python master. If you have to sit down with the interactive interpreter and experiment for a bit to understand it, you're doing pretty well. That pretty much is the point I'm trying to make. If the code is so complicated that masters can only understand it after a couple of minutes of thought, and those of us who are just doing pretty well need to sit down and puzzle it out in the REPL, then it's too complicated for most people to understand. KISS beats elegant. Now that I understand all the intricacies (thanks everyone!), this is how I would write it: def zip(*args): if not args: return iters = list(map(iter, args)) while True: try: result = [next(it) for it in iters] except StopIteration: return yield tuple(result) The implicit use of StopIteration to end the entire generator is far too implicit for my taste. This code expresses the intent much better. And good call on not being able to use: tuple(next(it) for it in iters) Again, the tricky implicit hidden StopIterations are confusing. One last tweak: why do we use map to make iters, but a list comprehension to make result? OK, let's try this: result = map(next, iters) Oops, another infinite loop on Py3, right, because map is lazy, so the StopIteration doesn't happen until the tuple() call. OK, try this: result = list(map(next, iters)) Nope, still infinite because now list() consumes the StopIteration again. Ugh. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
My understanding from talking to different people is that many do use tabs (instead of spaces) for indentation in their code. My question is to them (because I want to use tabs too) is: how do you maintain a line-length of 79 characters? E.g. scenario: The tab setting in your editor could be 2 or 4, and in other developer's browser it could be 8. The code will be longer than 79 chars in the latter's editor. I want to know if it's at all possible or if you use some simple and realistic (practical) hacks. *PS: Please avoid, That's why you should use spaces, type of comments. I would like to avoid flame wars.* TY, Aahan -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
On Mon, Dec 8, 2014 at 1:15 PM, Aahan Krish kr...@aahan.me wrote: My question is to them (because I want to use tabs too) is: how do you maintain a line-length of 79 characters? E.g. scenario: The tab setting in your editor could be 2 or 4, and in other developer's browser it could be 8. The code will be longer than 79 chars in the latter's editor. Easy: You stop fretting about 79 characters. :) If your policy is lines are no more than 80-100 characters long, then the difference between 4-space tabs and 8-space won't break stuff unless it was already marginal. So if you run 4-space (or 2-space) indentation, you just make sure you keep your lines to the lower end of the limit. Even better, don't quibble about any sort of specific limit, and just have a policy of don't make stuff so long that it's unreadable, and don't put silly arbitrary rules on your programmers. That's my policy. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
One reason why you would want max length 79 is because of working with terminals. Maybe ssh to you server and check how many spaces are consumed by a tab? In my boxes, it is usually 1 tab = 8 spaces. So perhaps just use that setting in your editor? On Mon, Dec 8, 2014 at 10:15 AM, Aahan Krish kr...@aahan.me wrote: My understanding from talking to different people is that many do use tabs (instead of spaces) for indentation in their code. My question is to them (because I want to use tabs too) is: how do you maintain a line-length of 79 characters? E.g. scenario: The tab setting in your editor could be 2 or 4, and in other developer's browser it could be 8. The code will be longer than 79 chars in the latter's editor. I want to know if it's at all possible or if you use some simple and realistic (practical) hacks. *PS: Please avoid, That's why you should use spaces, type of comments. I would like to avoid flame wars.* TY, Aahan -- https://mail.python.org/mailman/listinfo/python-list -- Freelance Grails http://grails.asia/ and Java http://javadevnotes.com/ developer -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
On Mon, Dec 8, 2014 at 10:23 AM, Chris Angelico ros...@gmail.com wrote: On Mon, Dec 8, 2014 at 1:15 PM, Aahan Krish kr...@aahan.me wrote: My question is to them (because I want to use tabs too) is: how do you maintain a line-length of 79 characters? E.g. scenario: The tab setting in your editor could be 2 or 4, and in other developer's browser it could be 8. The code will be longer than 79 chars in the latter's editor. Easy: You stop fretting about 79 characters. :) I agree with this. Just settle with your team what's your standard and have similar IDE settings. If your policy is lines are no more than 80-100 characters long, then the difference between 4-space tabs and 8-space won't break stuff unless it was already marginal. So if you run 4-space (or 2-space) indentation, you just make sure you keep your lines to the lower end of the limit. Even better, don't quibble about any sort of specific limit, and just have a policy of don't make stuff so long that it's unreadable, and don't put silly arbitrary rules on your programmers. That's my policy. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- Freelance Grails http://grails.asia/ and Java http://javadevnotes.com/ developer -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Iterables struggling using map() built-in
On 2014-12-08 01:00, Chris Angelico wrote: On Mon, Dec 8, 2014 at 11:45 AM, Roy Smith r...@panix.com wrote: I take it as result, which makes plenty of sense to me. OK, so spell it out. Three more keystrokes (well, plus another three when you use it on the next line). And one of them is a vowel; they don't even cost much. The next guy who has to read your code will thank you for it. Maybe. Personally, I don't mind the odd abbreviation; they keep the code small enough to eyeball, rather than spelling everything out everywhere. Using cur (or curr) for current, next for next, prev for previous, as prefixes to a short word saying *what* they're the current/next/previous of, is sufficiently obvious IMO to justify the repeated use of the abbreviation. Why does Python have int and str rather than integer and string? Or, worse, arbitrary_precision_integer and unicode_codepoint_string? Common words get shortened - it's a legit form of Huffman compression. Not to mention len, def, iter, etc. -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
On 12/7/14 9:15 PM, Aahan Krish wrote: My understanding from talking to different people is that many do use tabs (instead of spaces) for indentation in their code. My question is to them (because I want to use tabs too) is: how do you maintain a line-length of 79 characters? E.g. scenario: The tab setting in your editor could be 2 or 4, and in other developer's browser it could be 8. The code will be longer than 79 chars in the latter's editor. I want to know if it's at all possible or if you use some simple and realistic (practical) hacks. *PS: Please avoid, That's why you should use spaces, type of comments. I would like to avoid flame wars.* Pointing out that spaces make more sense is not a flame war. You are here asking how to deal with the variability inherent in tabs. Spaces don't have that problem. That is not flaming. That's solving your problem. I'm curious why you care about the 79 characters part of PEP8 if you don't care about the use spaces part of PEP8. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
Hi Ned, I'm curious why you care about the 79 characters part of PEP8 if you don't care about the use spaces part of PEP8. It's just that I don't like arbitrary rules. IMHO, spaces aren't better than tabs, and people should refrain from saying that. Both have their fair bit of disadvantages and it finally comes down to personal/team preference or consistency. I like tabs because they are flexible. As of now I am still considering spaces for two reasons—(1) maintaining a standard line-length of 79-120 characters; (2) Even if I use tabs, I may need spaces for aligning. I have no major projects now, so I am free to decide, and am taking my time for a well-thought decision. As for why I care the 79 chars part of PEP 8: - Coding in terminals and VIM with multiple windows open. - Avoiding horizontal scrollbars for code blocks on the web; GitHub for instance. E.g. https://github.com/torvalds/linux/blob/master/kernel/async.c -- That is good! - Readability; The same reason why people suggest short paragraphs, i.e. allow readers to quickly go through your content, or in my case, code. Best, Aahan -- https://mail.python.org/mailman/listinfo/python-list
Reasons for source code line length limits (was: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?)
jtan ad...@grails.asia writes: One reason why you would want max length 79 is because of working with terminals. That reason is decreasingly relevant as terminals become virtual, in a display window that can be much larger if we choose. Much more relevant is the ability to have two or even three code windows side-by-side, for comparison during a merge operation. For this purpose, a 75–80 column limit is a great help. But regardless of display technology, the biggest reason to stick to a limit like 80 or less is: reader technology. The ability for humans to comprehend long lines of text is poor, and there *is* a cognitive point beyond which it's not helpful to have longer lines. That line-length limit is different for different people, and many readers (and especially code writers) will fool themselves that they can read longer lines while unknowingly harming their comprehension. But for sure, it remains relatively constant across generations of humans, no matter how the display capacity increases. -- \ “If you can't annoy somebody there is little point in writing.” | `\—Kingsley Amis | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
On Mon, Dec 8, 2014 at 3:39 PM, Aahan Krish kr...@aahan.me wrote: As for why I care the 79 chars part of PEP 8: - Coding in terminals and VIM with multiple windows open. Then measure your width with tabs set to 8 spaces, and nothing else matters. Otherwise, go back to your previous statement about avoiding arbitrary rules, maximize your terminal window (let's see, if I hit Alt-F10 on my Xfce system, I get a terminal window that's 51 rows, 190 columns; F11 increases that to 55 rows), and ignore the precise counts. All your other points are just as valid with 82 characters as with 79, and pretty much as valid with anything up to about 100-120. - Avoiding horizontal scrollbars for code blocks on the web; GitHub for instance. E.g. https://github.com/torvalds/linux/blob/master/kernel/async.c -- That is good! It goes to 100 frequently, and I found one line that went to 126... if that's your idea of good, then I think going as far as 100 in your own code shouldn't be a problem. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Reasons for source code line length limits (was: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?)
On Mon, Dec 8, 2014 at 3:44 PM, Ben Finney ben+pyt...@benfinney.id.au wrote: But regardless of display technology, the biggest reason to stick to a limit like 80 or less is: reader technology. The ability for humans to comprehend long lines of text is poor, and there *is* a cognitive point beyond which it's not helpful to have longer lines. This is true. However, the human eye tends to ignore leading indentation to some degree, so in terms of the original question (which referred to tabs vs spaces and how that interacts with the line length limit), it's even less important to worry about exact character counts. Sure, a 500-character line is less readable than a 75-character line. But how much difference is there between 79 and, say, 90? I'd say there's more variation between different people than that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
Chris Angelico ros...@gmail.com writes: On Mon, Dec 8, 2014 at 1:15 PM, Aahan Krish kr...@aahan.me wrote: My question is to them (because I want to use tabs too) is: how do you maintain a line-length of 79 characters? E.g. scenario: The tab setting in your editor could be 2 or 4, and in other developer's browser it could be 8. The code will be longer than 79 chars in the latter's editor. Easy: You stop fretting about 79 characters. :) The question is a good one, especially when one considers the use of an automated test to detect lines which violate an agreed style guide. If your policy is lines are no more than 80-100 characters long, Such a policy still needs to know how many columns a U+0009 TAB character is to be counted, if an automated test is to be useful. You may not find value in such an automated “does this code meet the agreed style guide?” test, but many do. Perhaps the OP is one. -- \ “How wonderful that we have met with a paradox. Now we have | `\some hope of making progress.” —Niels Bohr | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?
Aahan Krish kr...@aahan.me writes: It's just that I don't like arbitrary rules. IMHO, spaces aren't better than tabs, and people should refrain from saying that. Simplicity has value. The rule “use four spaces for indentation” is simple to stick to, and simple to obtain sane display results by default. Using U+0009 characters for indentation is objectively more complex, because of the addition of all the special treatment of U+0009 characters, and especially the admonitions needed to readers not to use the attractive editor features of customising U+0009 rendering. So, you may decide the simplicity is less valuable than the ability to change the rendering of this special U+0009 character. But, if one values that simplicity, then U+0020 characters *are* better than U+0009 characters for indentation. So, no, I will not refrain from saying that. -- \ “You can be a victor without having victims.” —Harriet Woods, | `\ 1927–2007 | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Reasons for source code line length limits
Chris Angelico ros...@gmail.com writes: Sure, a 500-character line is less readable than a 75-character line. So we agree that merely being able to *display* more text on a line is not a reason to have arbitrarily-long lines of code. Good! But how much difference is there between 79 and, say, 90? I'd say there's more variation between different people than that. Of course there is. The argument then becomes one of picking a standard and sticking to it, since doing so saves an enormous amount of wasted time arguing. Much as we can agree that driving a vehicle on public roads at 500 km/h is too fast, but there is variation among people as to exactly how fast they can safely drive a vehicle. Once we've agreed there *is* such a thing as a harmfully-fast speed and that we should forbid speeds that are too fast, the variations of driver skill matter much less than picking one speed limit for a zone, telling everyone they must stick to it, and ending pointless arguments about where exactly to put the threshold. -- \ “I have never imputed to Nature a purpose or a goal, or | `\anything that could be understood as anthropomorphic.” —Albert | _o__)Einstein, unsent letter, 1955 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Iterables struggling using map() built-in
Steven D'Aprano wrote: I do not believe that good code must be obviously right. It's okay for code to be subtly right. If you write code as subtly as you can, you're not subtle enough to debug it... -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Iterables struggling using map() built-in
Terry Reedy wrote: However, this 'beautiful' code has a trap. If one gets rid of the seemingly unneeded temporary list res by telescoping the last two lines into a bit too much into yield tuple(next(i) for i in iters) we now have an infinite generator, because tuple() swallows the StopIteration raised as a side-effect of next calls. An excellent example of the kind of thing that PEP 479 is designed to catch! There couldn't be a better advertisement for it. :-) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python, C++ interaction
Cython and number it is... they definitely rule! But of course I am also interfacing my python code (with all the structuring and UI and object orientation) with some sse and fortran. if u can get a grip of programming fortran/sse, they work too On 12/7/14, Mark Lawrence breamore...@yahoo.co.uk wrote: On 07/12/2014 15:05, Sturla Molden wrote: On 05/12/14 23:17, wesleiram...@gmail.com wrote: m'giu vous êtès nom souris, pseudo nom cha'rs out oiu êtès, i'ret egop c'hâse I have not idea what that means, but I am sure it would be interesting if I knew French (or whatever it is). Please be careful, the guy who was selling forged Hungarian phrase books might now be selling French ones :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Reasons for source code line length limits
On 12/7/2014 11:44 PM, Ben Finney wrote: Much more relevant is the ability to have two or even three code windows side-by-side, for comparison during a merge operation. For this purpose, a 75–80 column limit is a great help. Or Idle Shell | Idle editor1 | Idle editor2 Editor 1 has file being being tested. Editor 2 has test file. Write test_xyy, F5, if pass, repeat, else fail, figure out whether test or code is bad. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Python re.search simple question
Hi Folks ,
This might seem to be very trivial question but iam breaking my head over
it for a while .
My understanding is that re.search should search for the match anywhere in
the string .
why is re.search failing in the below case ??
pattern
'Token-based migrations cannot be mixed with level-based: [prev 0 , now 1]'
text
' LogMessage {type NDMP_LOG_DBG} {msg_id 0} {msg The process id for NDMP
service is 0x9c216370} {associated_msg 0} {associated_msg_seq 0} Source
filer:DartOS Error: Token-based migrations cannot be mixed with
level-based: [prev 0 , now 1]'
if (re.search(pattern,text)):
...print Hi
... else:
... print BYE
...
BYE
Regards,
Ganesh
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python re.search simple question
Ganesh Pal writes: why is re.search failing in the below case ?? Your pattern, '... level-based: [prev 0 , now 1]', matches a literal string '--- level-based: ' followed by 'p', 'r', 'e', 'v', ' ', '0', ..., or '1', none of which is the '[' found in your text at that position. Are you sure you need a regexp? If you are, make your pattern r'... \[prev 0 , now 1\]'. The 'r' is not a typo. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python re.search simple question
On Dec 08 at 12:22 +0530, Ganesh Pal wrote:
Hi Folks ,
This might seem to be very trivial question but iam breaking my head over
it for a while .
My understanding is that re.search should search for the match anywhere in
the string .
why is re.search failing in the below case ??
pattern
'Token-based migrations cannot be mixed with level-based: [prev 0 , now 1]'
I sense a bad smell. Be sure to escape the bracket [ ]
text
' LogMessage {type NDMP_LOG_DBG} {msg_id 0} {msg The process id for NDMP
service is 0x9c216370} {associated_msg 0} {associated_msg_seq 0} Source
filer:DartOS Error: Token-based migrations cannot be mixed with
level-based: [prev 0 , now 1]'
if (re.search(pattern,text)):
...print Hi
... else:
... print BYE
...
so see here: https://bpaste.net/show/d2f1cf66a492 . It prints HI
/me always wishes code is sent without others doing some extra formatting
before testing.
Hope that helps.
--
Shiyao Ma
http://introo.me
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python re.search simple question
On Mon, Dec 8, 2014 at 12:52 AM, Ganesh Pal ganesh1...@gmail.com wrote: Hi Folks , This might seem to be very trivial question but iam breaking my head over it for a while . My understanding is that re.search should search for the match anywhere in the string . why is re.search failing in the below case ?? pattern 'Token-based migrations cannot be mixed with level-based: [prev 0 , now 1]' Your pattern here contains a character class ([enoprvw 01,]). You'll need to escape the '[' character to make it literal. Hope this helps, -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: Python re.search simple question
Jussi Piitulainen writes: Ganesh Pal writes: why is re.search failing in the below case ?? Your pattern, '... level-based: [prev 0 , now 1]', matches a literal string '--- level-based: ' followed by 'p', 'r', 'e', 'v', ' ', '0', ..., or '1', none of which is the '[' found in your text at that position. Are you sure you need a regexp? If you are, make your pattern r'... \[prev 0 , now 1\]'. The 'r' is not a typo. On the other hand, the '---' *is* a typo, meant to be an ellipsis where I shortened your text. The shortened pattern would still match it, but that's an accident: '.' has a special meaning in a regexp. Sorry about that. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python re.search simple question
Thanks guys , I escaped the '[' character and my issue is sloved .. Thank you guys u all rock :) Regards, Ganesh On Mon, Dec 8, 2014 at 12:41 PM, Zachary Ware zachary.ware+pyl...@gmail.com wrote: On Mon, Dec 8, 2014 at 12:52 AM, Ganesh Pal ganesh1...@gmail.com wrote: Hi Folks , This might seem to be very trivial question but iam breaking my head over it for a while . My understanding is that re.search should search for the match anywhere in the string . why is re.search failing in the below case ?? pattern 'Token-based migrations cannot be mixed with level-based: [prev 0 , now 1]' Your pattern here contains a character class ([enoprvw 01,]). You'll need to escape the '[' character to make it literal. Hope this helps, -- Zach -- https://mail.python.org/mailman/listinfo/python-list
[issue22939] integer overflow in iterator object
STINNER Victor added the comment: You should not rely on undefined behaviour: check if the index is greater or equal than PY_SSIZET_MAX - 1. __setstate__ must implement the same check. You must always raise an error, not hide it in a second call to next (raise StopIteration). Your unit test must check this behaviour. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22939 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
STINNER Victor added the comment: Why not using on Windows the same naming scheme than Unix. It may be useful to also add the debug flag (d) in the name for example. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22939] integer overflow in iterator object
Serhiy Storchaka added the comment: check if the index is greater or equal than PY_SSIZET_MAX - 1. Just PY_SSIZET_MAX. Added other comments on Rietveld (look the email in the Spam folder). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22939 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23003] traceback.{print_exc, print_exception, format_exc, format_exception}: Potential AttributeError
Changes by Berker Peksag berker.pek...@gmail.com: -- keywords: +patch nosy: +berker.peksag stage: - patch review type: - behavior Added file: http://bugs.python.org/file37380/issue23003.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23003 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Steve Dower added the comment: Why not using on Windows the same naming scheme than Unix. It may be useful to also add the debug flag (d) in the name for example. Windows already puts the debug flag in the name, the fact that it's CPython is in the .pyd extension, and the version number is in the directory for all the standard sys.path locations. Platform is the only variable unaccounted for. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23004] mock_open() should allow reading binary data
New submission from Jesús Cea Avión:
mock_open(read_data=b'...') gives an error:
Traceback (most recent call last):
File z.py, line 6, in module
print(f.read())
File /usr/local/lib/python3.4/unittest/mock.py, line 896, in __call__
return _mock_self._mock_call(*args, **kwargs)
File /usr/local/lib/python3.4/unittest/mock.py, line 962, in _mock_call
ret_val = effect(*args, **kwargs)
File /usr/local/lib/python3.4/unittest/mock.py, line 2279, in
_read_side_effect
return ''.join(_data)
File /usr/local/lib/python3.4/unittest/mock.py, line 2244, in
_iterate_read_data
data_as_list = ['{}\n'.format(l) for l in read_data.split('\n')]
Easy to reproduce:
from unittest.mock import mock_open, patch
m = mock_open(read_data= b'abc')
with patch('__main__.open', m, create=True) :
with open('abc', 'rb') as f :
print(f.read())
Looks like this bug was introduced as result of issue #17467. I add those
people to the nosy list.
--
keywords: easy
messages: 232271
nosy: a.badger, jcea, michael.foord
priority: normal
severity: normal
status: open
title: mock_open() should allow reading binary data
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23004
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17467] Enhancement: give mock_open readline() and readlines() methods
Changes by Jesús Cea Avión j...@jcea.es: -- superseder: - mock_open() should allow reading binary data ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17467 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23004] mock_open() should allow reading binary data
Changes by Jesús Cea Avión j...@jcea.es: -- dependencies: +Enhancement: give mock_open readline() and readlines() methods ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23004 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23003] traceback.{print_exc, print_exception, format_exc, format_exception}: Potential AttributeError
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23003 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23004] mock_open() should allow reading binary data
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +berker.peksag stage: - needs patch type: - behavior versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23004 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Antoine Pitrou added the comment: Windows already puts the debug flag in the name, the fact that it's CPython is in the .pyd extension, and the version number is in the directory for all the standard sys.path locations. The version number would be useful for in-place builds (i.e. when developping), but the patch is still a nice step forward. Could you perhaps add some tests (e.g. in test_distutils)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23005] typos on heapq doc
New submission from Martin Matusiak: - which are pre-sorted sequences, which size is usually related to the amount of CPU memory whose size - Tournaments are a good way to that. Tournaments are a good way to achieve that. -- components: Library (Lib) files: heapq_docs_typos.diff keywords: patch messages: 232273 nosy: ned.deily, numerodix priority: normal severity: normal status: open title: typos on heapq doc type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37381/heapq_docs_typos.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23005 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22959] http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False
Roundup Robot added the comment: New changeset a409a7cd908d by Benjamin Peterson in branch '3.4': HTTPSConnection: prefer the context's check_hostname attribute over the constructor parameter (#22959) https://hg.python.org/cpython/rev/a409a7cd908d New changeset 41021c771510 by Benjamin Peterson in branch '2.7': remove HTTPSConnection's check_hostname parameter (#22959) https://hg.python.org/cpython/rev/41021c771510 New changeset ee095a2e2b35 by Benjamin Peterson in branch 'default': merge 3.4 (#22959) https://hg.python.org/cpython/rev/ee095a2e2b35 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22959] http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False
Benjamin Peterson added the comment: Okay, I basically applied my patch to 3.4/3.5. I simply removed the check_hostname parameter from 2.7, since it was to be added in 2.7.9. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23005] typos on heapq doc
Changes by Ned Deily n...@acm.org: -- assignee: - docs@python components: +Documentation -Library (Lib) nosy: +docs@python -ned.deily versions: -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23005 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20603] sys.path disappears at shutdown
Brett Cannon added the comment: Since issue #19255 is closed is this still an issue, Antoine? -- assignee: - pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20603 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Steve Dower added the comment: The version number would be useful for in-place builds (i.e. when developping) Ah, I see now how that would be useful (I haven't tried to deal with that before). I'll revise the patch to use/allow the version number. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20603] sys.path disappears at shutdown
Antoine Pitrou added the comment: I don't know. Not for issue #19255 obviously, so we can probably close :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20603 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9536] defaultdict doc makes incorrect reference to __missing__ method
Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9536 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23006] Improve the doc and indexing of adict.__missing__.
New submission from Terry J. Reedy: Currently, the only index entry for __missing__ is __missing__() (collections.defaultdict method). This entry should probably not exist -- see #9536, which inspired this issue. The method is not mentioned in the special-methods doc, and the explanation in the dict doc is not indexed. Two suggestions: https://docs.python.org/3/reference/datamodel.html#emulating-container-types After __getitem__ entry, add automatically indexed entry, something like object.__missing__(self, key): When present in a dict subclass, called by dict.__getitem__ for missing keys. https://docs.python.org/3/library/stdtypes.html#mapping-types-dict Before the d[key] paragraph starting If a subclass of dict defines a method __missing__() add explicit __missing__ index directive. The last sentence of the paragraph See collections.Counter for a complete implementation including other methods helpful for accumulating and managing tallies. is confusing because the linked entry makes no mention of __missing__ (as it should not). Change sentence to something like There are two stdlib dict subclasses that use (different) __missing__ methods as part of their implementation: collections.Counter and collections.defaultdict. I will work on a patch and try to get the markup correct. -- assignee: docs@python components: Documentation messages: 232279 nosy: docs@python, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Improve the doc and indexing of adict.__missing__. type: behavior versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23006 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9647] os.confstr() does not handle value changing length between calls
David Watson added the comment: On Fri 5 Dec 2014, STINNER Victor wrote: I added an assertion. Can we close this issue? Well, if no one complains about the interpreter dying with SIGABRT, that will suggest that the worries about OS bugs creating infinite loops were unfounded :) If you do want to leave this open, I can provide patches based on the original one from issue #9579. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9647 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9536] defaultdict doc makes incorrect reference to __missing__ method
Terry J. Reedy added the comment: I agree that the patch is not acceptable as is. The public attribute *defaultdict* should be explicitly documented as it is now, so that it is indexed. On the other hand, users should not directly call .__missing__, and it is not normal to document the private special method implementation of classes. For example, a collections.Counter returns 0 for missing keys but the doc makes no mention of .__missing__ as the implementation. It simply describe how a counter works. John is correct that people writing other subclasses with __missing__ should usually subclass dict. This might be clearer if that special method were properly documented and indexed. I opened #23006 for this. -- nosy: +terry.reedy resolution: not a bug - stage: resolved - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9536 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22939] integer overflow in iterator object
Clement Rouault added the comment: Thanks for the comments. I corrected the patch and updated the test. I also added a test that check the behavior of setstate with negative indice. Just one question: __setstate__ must implement the same check. Why should __setstate__ check for PY_SSIZE_T_MAX (throwing OverflowError when unpickling) if the check will be done when calling next on the resulting iterator ? -- Added file: http://bugs.python.org/file37382/issue22939v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22939 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9647] os.confstr() does not handle value changing length between calls
Serhiy Storchaka added the comment: I don't think that assert() is appropriate solution here. assert() is used to check internal logic, it shouldn't check conditions which rely on external world. Raising RuntimeError looks more appropriate to me. -- versions: -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9647 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22939] integer overflow in iterator object
Serhiy Storchaka added the comment: __setstate__ should check that an index is not negative. All values from 0 to PY_SSIZE_T_MAX are acceptable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22939 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22939] integer overflow in iterator object
Serhiy Storchaka added the comment: Ah, __setstate__ already handles negative indices. Then the patch LGTM. -- stage: needs patch - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22939 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23006] Improve the doc and indexing of adict.__missing__.
Changes by Terry J. Reedy tjre...@udel.edu: -- keywords: +patch Added file: http://bugs.python.org/file37383/__missing__.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23006 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23006] Improve the doc and indexing of adict.__missing__.
Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23006 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23007] Unnecessary big intermediate result in Lib/bisect.py
New submission from Sergey Litvinov: Bisection algorithms use mid = (lo+hi)//2 Textbook formula is mid = (hi-lo)//2 + lo See http://en.wikipedia.org/w/index.php?title=Binary_search_algorithmoldid=634658510#Arithmetic For vanilla lists and integers it is not a problem but one can run into troubles with user defined types. -- components: Library (Lib) messages: 232286 nosy: Sergey.Litvinov priority: normal severity: normal status: open title: Unnecessary big intermediate result in Lib/bisect.py type: behavior versions: Python 2.7, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23007 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1225584] crash in gcmodule.c on python reinitialization
Terry J. Reedy added the comment: I am closing since the initial problem has been fixed and there is no known current problem to fix. If someone does discover one, they can reopen or, probably better, open a new issue. -- resolution: - fixed stage: test needed - resolved status: languishing - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1225584 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1425127] os.remove OSError: [Errno 13] Permission denied
Changes by Terry J. Reedy tjre...@udel.edu: -- resolution: - out of date stage: test needed - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1425127 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18305] [patch] Fast sum() for non-numbers
Terry J. Reedy added the comment: Sergey, please stop calling the current documented behavior a bug. https://docs.python.org/3/library/functions.html#sum says 'The iterable‘s items are normally numbers ... To concatenate a series of iterables, consider using itertools.chain(). To make a change, there must be discussion and approval on python-ideas, including by Guido. I believe that GvR's rejection of optimizing for strings covers optimizing for other sequences. If you want to continue, make a pep-like post there that summarizes the discussion here and makes your current proposal. -- versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18305 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19451] urlparse accepts invalid hostnames
Changes by Terry J. Reedy tjre...@udel.edu: -- resolution: - wont fix stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19451 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22959] http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False
zodalahtathi added the comment: Thank you -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19846] Python 3 raises Unicode errors with the C locale
Terry J. Reedy added the comment: Since Viktor's alternative in #19977 has been applied, should this issue be closed? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19846 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20866] segfailt with os.popen and SIGPIPE
Terry J. Reedy added the comment: Does anyone disagree with closing this as Won't fix'? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20866 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
