Re: Python re.search simple question

[Ganesh Pal]

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  wrote:

> On Mon, Dec 8, 2014 at 12:52 AM, 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]'
>
> 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]

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

[Zachary Ware]

On Mon, Dec 8, 2014 at 12:52 AM, 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]'

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

[Shiyao Ma]

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

[Jussi Piitulainen]

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

Python re.search simple question

[Ganesh Pal]

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: Reasons for source code line length limits

[Terry Reedy]

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

Re: Python, C++ interaction

[Gayathri J]

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  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: Python Iterables struggling using map() built-in

[Gregory Ewing]

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 Iterables struggling using map() built-in

[Gregory Ewing]

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: Reasons for source code line length limits

[Ben Finney]

Chris Angelico  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: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?

[Ben Finney]

Aahan Krish  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: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?

[Ben Finney]

Chris Angelico  writes:

> On Mon, Dec 8, 2014 at 1:15 PM, Aahan Krish  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: Reasons for source code line length limits (was: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?)

[Chris Angelico]

On Mon, Dec 8, 2014 at 3:44 PM, Ben Finney  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]

On Mon, Dec 8, 2014 at 3:39 PM, Aahan Krish  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

Reasons for source code line length limits (was: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?)

[Ben Finney]

jtan  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?

[Aahan Krish]

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

Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?

[Ned Batchelder]

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: Python Iterables struggling using map() built-in

[MRAB]

On 2014-12-08 01:00, Chris Angelico wrote:

On Mon, Dec 8, 2014 at 11:45 AM, Roy Smith  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?

[jtan]

On Mon, Dec 8, 2014 at 10:23 AM, Chris Angelico  wrote:

> On Mon, Dec 8, 2014 at 1:15 PM, Aahan Krish  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  and Java 
 developer
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?

[jtan]

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  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  and Java 
 developer
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Maintaining Maximum Line Length When Using Tabs Instead of Spaces?

[Chris Angelico]

On Mon, Dec 8, 2014 at 1:15 PM, Aahan Krish  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

Maintaining Maximum Line Length When Using Tabs Instead of Spaces?

[Aahan Krish]

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: Python Iterables struggling using map() built-in

[Ned Batchelder]

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  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

Re: Python Iterables struggling using map() built-in

[Chris Angelico]

On Mon, Dec 8, 2014 at 11:45 AM, Roy Smith  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

[Roy Smith]

In article ,
 Chris Angelico  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

[Terry Reedy]

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  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

[Chris Angelico]

On Mon, Dec 8, 2014 at 11:27 AM, Roy Smith  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

[Chris Angelico]

On Mon, Dec 8, 2014 at 11:12 AM, Roy Smith  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

[Roy Smith]

In article ,
 Chris Angelico  wrote:

> On Mon, Dec 8, 2014 at 10:33 AM, Steven D'Aprano
>  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

[Roy Smith]

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  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: Nested dictionaries from a list ?

[Denis McMahon]

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]

On Mon, Dec 8, 2014 at 10:33 AM, Steven D'Aprano
 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 ?

[Denis McMahon]

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

[Steven D'Aprano]

Chris Angelico wrote:

> On Mon, Dec 8, 2014 at 5:27 AM, Ian Kelly  wrote:
>> On Dec 7, 2014 8:31 AM, "Ned Batchelder"  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

ANN: A new version (0.3.7) of python-gnupg has been released.

[Vinay Sajip]

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) 
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) ']},
 {
  ...
  'fingerprint': '37F24DD4B918CC264D4F31D60C5FEFA7A921FC4A',
  'keyid': '0C5FEFA7A921FC4A',
  'length': '1024',
  ...
  'uids': ['', 'Danny Davis (A test user) ']}]
>>> 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: Tuple of lists concatenation - function vs comprehension

[Terry Reedy]

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

Re: Setting default_factory of defaultdict to key

[Terry Reedy]

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: Python Iterables struggling using map() built-in

[Chris Angelico]

On Mon, Dec 8, 2014 at 5:27 AM, Ian Kelly  wrote:
> On Dec 7, 2014 8:31 AM, "Ned Batchelder"  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: Python Iterables struggling using map() built-in

[Ian Kelly]

On Dec 7, 2014 8:31 AM, "Ned Batchelder"  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

[Chris Angelico]

On Mon, Dec 8, 2014 at 2:29 AM, Ned Batchelder  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: Setting default_factory of defaultdict to key

[Ian Kelly]

On Dec 7, 2014 9:33 AM, "Dave Angel"  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, C++ interaction

[Mark Lawrence]

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

[Dave Angel]

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

Different “reply” functions: reply-to-sender, reply-to-list, reply-to-all (was: Setting default_factory of defaultdict to key)

[Ben Finney]

Shiyao Ma  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.

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: Nested dictionaries from a list ?

[Dave Angel]

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

Re: Setting default_factory of defaultdict to key

[Shiyao Ma]

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: Setting default_factory of defaultdict to key

[Dave Angel]

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: module import questions and question about pytest and module imports

[Dave Angel]

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

Nested dictionaries from a list ?

[Wacky]

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: Python Iterables struggling using map() built-in

[Ivan Evstegneev]

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 "", line 1, in 
>
>   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)))
>
> [,
>
> ,
>
> ,
>
> ]
>

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 list of values, and line 5 makes a tuple of them to r

RE: Tuple of lists concatenation - function vs comprehension

[Ivan Evstegneev]

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: Tuple of lists concatenation - function vs comprehension

[Shiyao Ma]

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

Tuple of lists concatenation - function vs comprehension

[Ivan Evstegneev]

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: Python, C++ interaction

[Sturla Molden]

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

how to install paramiko correctly?

[sir]

My system:win7+python3.4 .
I have installed Crypto and Paramiko .

C:\Windows\system32>pip3.4  install  Crypto
Requirement already satisfied (use --upgrade to upgrade): Crypto in 
d:\python34\

lib\site-packages
Cleaning up...

C:\Windows\system32>pip3.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 "", line 1, in 
  File "D:\Python34\lib\site-packages\paramiko\__init__.py", line 
30, in 
  from paramiko.transport import SecurityOptions, Transport
  File "D:\Python34\lib\site-packages\paramiko\transport.py", line 
49, in 

 from paramiko.dsskey import DSSKey
 File "D:\Python34\lib\site-packages\paramiko\dsskey.py", line 26, 
in 

 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 "", line 1, in 
  File 
"F:\Python34\lib\site-packages\paramiko-1.13.0-py3.4.egg\paramiko\__in

_.py", line 31, in 
  File 
"F:\Python34\lib\site-packages\paramiko-1.13.0-py3.4.egg\paramiko\tran

rt.py", line 30, in 
  File 
"F:\Python34\lib\site-packages\paramiko-1.13.0-py3.4.egg\paramiko\util

", line 34, in 
  File 
"F:\Python34\lib\site-packages\paramiko-1.13.0-py3.4.egg\paramiko\comm

py", line 129, in 
ImportError: cannot import name 'Random'


How can i solve the problem?


--
https://mail.python.org/mailman/listinfo/python-list

Re: jitpy - Library to embed PyPy into CPython

[Albert-Jan Roskam]

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

The preferred way to implement a new transport in asyncio

[Jonas Wielicki]

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: Python Iterables struggling using map() built-in

[Chris Angelico]

On Sun, Dec 7, 2014 at 3:44 AM, Ivan Evstegneev  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 "", line 1, in 
>
> next(k)
>
>   File "", 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

Python Iterables struggling using map() built-in

[Ivan Evstegneev]

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 "", line 1, in 

next(k)

  File "", 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)



 

>>> next(k)

1

 

>>> print(list(map(iter, L)))

Traceback (most recent call last):

  File "", line 1, in 

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



 

>>> next(string)

's'

 

and so on.

 

And then just tried this one:

 

>>> print(list(map(iter, S)))

[, 

, 

,

] -> 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 last):

  File "", line 1, in 

next(k[0])

StopIteration

 

So I may admit that I found the problem, but can't explain it to myself.

 

 

 

Finally I've che

Re: Setting default_factory of defaultdict to key

[John J Posner]

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

module import questions and question about pytest and module imports

[sam pendleton]

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

Help with exscript with Cisco asa

[Edward Manning]

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

Re: jitpy - Library to embed PyPy into CPython

[Stefan Behnel]

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