Re: a.index(float('nan')) fails

[Terry Reedy]

On 10/25/2012 10:44 PM, Steven D'Aprano wrote:

On Thu, 25 Oct 2012 22:04:52 -0400, Terry Reedy wrote:


It is a consequence of the following, which some people (but not all)
believe is mandated by the IEEE standard.

  >>> nan = float('nan')
  >>> nan is nan
True


The IEEE 754 standard says nothing about object identity. It only
discusses value equality.


  >>> nan == nan
False


IEEE 754 states that all NANs compare unequal to everything, including
NANs with the same bit value. It doesn't make an exception for
comparisons with itself.

I'm not entirely sure why you suggest that there is an argument about
what IEEE 754 says about NANs.


I did not do so.


As far as I can see, the argument is
whether or not language designers should pick and choose which bits of
the standard they want to follow, thus taking a step backwards to the
chaos of numerical computing prior to the IEEE 754 standard.


There has been disagreement about whether the standard mandates that 
Python behave the way it does. That is a fact, but I have no interest in 
discussing the issue.


--
Terry Jan Reedy

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

Re: a.index(float('nan')) fails

[Terry Reedy]

On 10/25/2012 10:19 PM, MRAB wrote:

On 2012-10-26 03:04, Terry Reedy wrote:

On 10/25/2012 9:46 PM, mambokn...@gmail.com wrote:

a = [float('nan'), 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
a

[nan, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

a.index(float('nan'))


This is a second nan object, and it is not in the list.


Traceback (most recent call last):
   File "", line 1, in 
ValueError: list.index(x): x not in list

That means, the function .index() cannot detect nan values.
It happens on both Python 2.6 and Python 3.1

Is this a bug? Or I am not using .index() correctly?


It is a consequence of the following, which some people (but not all)
believe is mandated by the IEEE standard.

  >>> nan = float('nan')
  >>> nan is nan
True
  >>> nan == nan
False

  >>> nanlist = [nan]
  >>> nan in nanlist
True
  >>> nanlist.index(nan)
0


.index found the nan.


Containment of nan in collection is tested by is, not ==.

  >>> nan2 = float('nan')
  >>> nan2 is nan
False
  >>> nan2 == nan
False
  >>> nan2 in nanlist
False


In summary, .index() looks for an item which is equal to its argument,
but it's a feature of NaN (as defined by the standard) that it doesn't
equal NaN, therefore .index() will never find it.


Except that is *does* find the particular nan object that is in the 
collection. So nan in collection and list.index(nan) look for the nan by 
identity, not equality. This inconsistency is an intentional decision to 
not propagate the insanity of nan != nan to Python collections.


--
Terry Jan Reedy

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

better way for ' '.join(args) + '\n'?

[Ulrich Eckhardt]

Hi!

General advise when assembling strings is to not concatenate them 
repeatedly but instead use string's join() function, because it avoids 
repeated reallocations and is at least as expressive as any alternative.


What I have now is a case where I'm assembling lines of text for driving 
a program with a commandline interface. In this scenario, I'm currently 
doing this:


  args = ['foo', 'bar', 'baz']
  line = ' '.join(args) + '\n'

So, in other words, I'm avoiding all the unnecessary copying, just to 
make another copy to append the final newline.


The only way around this that I found involves creating an intermediate 
sequence like ['foo', ' ', 'bar', ' ', 'baz', '\n']. This can be done 
rather cleanly with a generator:


  def helper(s):
  for i in s[:-1]:
   yield i
   yield ' '
  yield s[-1]
  yield '\n'
  line = ''.join(tmp(args))

Efficiency-wise, this is satisfactory. However, readability counts and 
that is where this version fails and that is the reason why I'm writing 
this message. So, dear fellow Pythonistas, any ideas to improve the 
original versions efficiency while preserving its expressiveness?


Oh, for all those that are tempted to tell me that this is not my 
bottleneck unless it's called in a very tight loop, you're right. 
Indeed, the overhead of the communication channel TCP between the two 
programs is by far dwarving the few microseconds I could save here. I'm 
still interested in learning new and better solutions though.



Cheers!

Uli

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

Re: bit count or bit set && Python3

[Antoon Pardon]

On 25-10-12 16:47, Charles Hixson wrote:
> In Python3 is there any good way to count the number of on bits in an
> integer (after an & operation)?
> Alternatively, is there any VERY light-weight implementation of a bit
> set?  I'd prefer to use integers, as I'm probably going to need
> thousands of these, if the tests work out.  But before I can test, I
> need a decent bit counter.  (shift, xor, &, and | are already present
> for integer values, but I also need to count the number of "true"
> items after the logical operation.  So if a bitset is the correct
> approach, I'll need it to implement those operations, or their
> equivalents in terms of union and intersection.)
>
> Or do I need to drop into C for this?
>
Some time ago I implemented this. Maybe you can use it as inspiration.

def CardSet(iter):
bits = 0L
for el in iter:
  bits = bits | (1L << el)
return CardSetType(bits)

def CSt(*args):
  return CardSet(args)

class CardSetType:
  def __init__(self, bits):
self.bits = bits

  def __str__(self):
return '{' + ','.join(map(str , self)) + '}'

  def __repr__(self):
return 'CSt(' + ','.join(map(str , self)) + ')'

  def __eq__(self, term):
return self.bits == term.bits

  def __contains__(self, el):
return (1L << el) & self.bits == 1L << el

  def __and__(self, term):
return CardSetType(self.bits & term.bits)

  def __or__(self, term):
return CardSetType(self.bits | term.bits)

  def __xor__(self, term):
return CardSetType(self.bits ^ term.bits)

  def __sub__(self, term):
return CardSetType(self.bits & ~term.bits)

  def __le__(self, term):
return self.bits & term.bits == self.bits

  def __ge__(self, term):
return self.bits | term.bits == self.bits

  def __len__(self):
bits = self.bits
full = 1L
shift = 1L
index = 0
mask = []
while full < bits:
  for i in range(index):
mask[i] = (mask[i] << shift) + mask[i]
  mask.append(full)
  full = (full << shift) + full
  index = index + 1
  shift = 2 * shift
shift = 1
for i in range(index):
  bits = ((bits >> shift) & mask[i]) + (bits & mask[i])
  shift = 2 * shift
return int(bits)

  def incl(self, el):
self.bits = self.bits | 1L << el

  def excl(self, el):
self.bits = self.bits & ~(1L << el)

  def __iter__(self):
return SetIterator(self.bits)

class SetIterator:

  def __init__(self, bits):
self.bits = bits
self.offset = 0

  def __iter__(self):
return self

  def next(self):
if self.bits == 0:
  raise StopIteration
else:
  while True:
shift = 0
delta = 1
full = 1L
while (self.bits & full) == 0:
  full = (full << delta) + full
  shift = delta
  delta = delta * 2
if shift == 0:
  break
self.offset = self.offset + shift
self.bits = self.bits >> shift
  result = self.offset
  self.offset = self.offset + 1
  self.bits = self.bits >> 1
  return result

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

Re: better way for ' '.join(args) + '\n'?

[Peter Otten]

Ulrich Eckhardt wrote:

> Hi!
> 
> General advise when assembling strings is to not concatenate them
> repeatedly but instead use string's join() function, because it avoids
> repeated reallocations and is at least as expressive as any alternative.
> 
> What I have now is a case where I'm assembling lines of text for driving
> a program with a commandline interface. In this scenario, I'm currently
> doing this:
> 
>args = ['foo', 'bar', 'baz']
>line = ' '.join(args) + '\n'
> 
> So, in other words, I'm avoiding all the unnecessary copying, just to
> make another copy to append the final newline.
> 
> The only way around this that I found involves creating an intermediate
> sequence like ['foo', ' ', 'bar', ' ', 'baz', '\n']. This can be done
> rather cleanly with a generator:
> 
>def helper(s):
>for i in s[:-1]:
> yield i
> yield ' '
>yield s[-1]
>yield '\n'
>line = ''.join(tmp(args))
> 
> Efficiency-wise, this is satisfactory. 

No, it is not. In a quick timeit test it takes 5 to 10 times as long as the 
original. Remember that function calls are costly, and that with s[:-1] you 
are trading the extra string for an extra list. Also, you are doubling the 
loop implicit in str.join() with the explicit one in your oh-so-efficient 
generator.

> However, readability counts and
> that is where this version fails and that is the reason why I'm writing
> this message. So, dear fellow Pythonistas, any ideas to improve the
> original versions efficiency while preserving its expressiveness?
> 
> Oh, for all those that are tempted to tell me that this is not my
> bottleneck unless it's called in a very tight loop, you're right.
> Indeed, the overhead of the communication channel TCP between the two
> programs is by far dwarving the few microseconds I could save here. I'm
> still interested in learning new and better solutions though.

Even if it were the bottleneck the helper generator approach would still be 
unhelpful.



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

Re: Quickie - Regexp for a string not at the beginning of the line

[Janis Papanagnou]

Am 26.10.2012 06:45, schrieb Rivka Miller:

Thanks everyone, esp this gentleman.


Who is "this"?



The solution that worked best for me is just to use a DOT before the
string as the one at the beginning of the line did not have any char
before it.


Which was what I suggested, and where you rudely answered...


no one has really helped yet.


And obviously...


I am a satisfied custormer.


...your perception about yourself and about the role of us
Usenet posters seems also not be very sane. Good luck.

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

Re: better way for ' '.join(args) + '\n'?

[Steven D'Aprano]

On Fri, 26 Oct 2012 09:49:50 +0200, Ulrich Eckhardt wrote:

> Hi!
> 
> General advise when assembling strings is to not concatenate them
> repeatedly but instead use string's join() function, because it avoids
> repeated reallocations and is at least as expressive as any alternative.
> 
> What I have now is a case where I'm assembling lines of text for driving
> a program with a commandline interface. In this scenario, I'm currently
> doing this:
> 
>args = ['foo', 'bar', 'baz']
>line = ' '.join(args) + '\n'
> 
> So, in other words, I'm avoiding all the unnecessary copying, just to
> make another copy to append the final newline.

*shrug*

The difference between ' '.join(sequence) and (' '.join(sequence) + '\n') 
is, in Big Oh analysis, insignificant. The first case does O(N) 
operations, the second does O(N) + O(N) = 2*O(N) operations, which is 
still O(N). In effect, the two differ only by an approximately constant 
factor.

If you really care, and you don't mind ending your last line with a 
space, just append '\n' to the sequence before calling join.


> The only way around this that I found involves creating an intermediate
> sequence like ['foo', ' ', 'bar', ' ', 'baz', '\n']. This can be done
> rather cleanly with a generator:
> 
>def helper(s):
>for i in s[:-1]:
> yield i
> yield ' '
>yield s[-1]
>yield '\n'
>line = ''.join(tmp(args))
> 
> Efficiency-wise, this is satisfactory. 

Have you actually tested this? I would not be the least surprised if 
that's actually less efficient than the (' '.join(seq) + '\n') version.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Steven D'Aprano]

On Fri, 26 Oct 2012 17:23:12 +1100, Chris Angelico wrote:

> Why is everyone skirting around C-style assignment expressions as though
> they're simultaneously anathema and the goal? :)

Only if your goal is to introduce an anathema :P


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about long-running web scripts

[Gilles]

On Thu, 25 Oct 2012 08:53:11 -0400, David Hutto
 wrote:
>>> OTOH, Python web scripts can be written as long-running scripts: In
>>> this case, what is the added-value of using FastCGI? Why can't the
>>> web server simply call the Python script directly, just like CGI?
>
>The server should call a the script, or script.sleep()
>
>There are also server options to setup when a script is run, other
>than a cron jo for php.

Thanks. Does it mean that Python scripts that rely on either fcgi.py
or WSGI really have some endless loop somewhere and will keep running
once they're launched by FastCGI?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about long-running web scripts

[Gilles]

On Thu, 25 Oct 2012 14:24:16 +0100, Tim Golden 
wrote:
>> But actually, I didn't mean one-shot scripts, where the Python
>> interpreter + script must be loaded each time, but rather: If I leave
>> a Python running in an endless loop, why not just use either CGI or
>> some other basic way to call the script instead of FastCGI?
>
>In essence, you're describing FastCGI. A Python program (or, indeed, any
>program) which uses FastCGI runs continuously and waits for the incoming
>request on a TCP socket (instead of as a sys.stdin stream + env vars
>immediately after process startup).

Thanks for the clarification.

Since, unlike PHP, the Python interpreter is not available in a
FastCGI-capable version, this explains why the www server must be told
which specific Python script to run through FastCGI.

The reason I ask for all this, is that I want to understand how things
work under the hood before relying on a Python framework to handle the
nitty-gritty.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Quickie - Regexp for a string not at the beginning of the line

[Asen Bozhilov]

Rivka Miller wrote:
> I am looking for a regexp for a string not at the beginning of the
> line.
>
> For example, I want to find $hello$ that does not occur at the
> beginning of the string, ie all $hello$ that exclude ^$hello$.

The begging of the string is zero width character. So you could use
negative lookahead (?!^).
Then the regular expression looks like:

/(?!^)\$hello\$/g

var str = '$hello$ should not be selected but',
str1 = 'not hello but all of the $hello$ and $hello$ ... $hello$
each one ';

str.match(/(?!^)\$hello\$/g); //null
str1.match(/(?!^)\$hello\$/g); //["$hello$", "$hello$", "$hello$"]



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

RE: Fastest web framework

[Andriy Kornatskyy]

Alex,

You can read wheezy.web introduction here:

http://mindref.blogspot.com/2012/10/wheezy-web-introduction.html

Thanks.

Andriy Kornatskyy


> Date: Mon, 15 Oct 2012 18:26:16 -0700
> Subject: Re: Fastest web framework
> From: wuwe...@gmail.com
> To: python-list@python.org
>
> On Oct 15, 11:40 pm, Andriy Kornatskyy 
> wrote:
> > Comments or suggestions are welcome.
>
> Performance speed is possibly the least interesting aspect of web
> frameworks; ease of use & readily re-usable 3rd party code figures
> much higher, IMO. Rather than constantly hammer on about performance,
> maybe you could take the time to explain any other advantages your
> framework provides.
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about long-running web scripts

[Tim Golden]

On 26/10/2012 10:58, Gilles wrote:
> On Thu, 25 Oct 2012 14:24:16 +0100, Tim Golden 
> wrote:
>>> But actually, I didn't mean one-shot scripts, where the Python
>>> interpreter + script must be loaded each time, but rather: If I leave
>>> a Python running in an endless loop, why not just use either CGI or
>>> some other basic way to call the script instead of FastCGI?
>>
>> In essence, you're describing FastCGI. A Python program (or, indeed, any
>> program) which uses FastCGI runs continuously and waits for the incoming
>> request on a TCP socket (instead of as a sys.stdin stream + env vars
>> immediately after process startup).
> 
> Thanks for the clarification.
> 
> Since, unlike PHP, the Python interpreter is not available in a
> FastCGI-capable version, this explains why the www server must be told
> which specific Python script to run through FastCGI.

I think that this is the distinction you're making:

PHP: mod_php (fastcgi mode) runs myscript.php

Python: .py runs myscript.py

which is, essentially, true, not least because PHP and web apps are
pretty much synonymous in many people's minds. Both ways: the only thing
PHP does is web; the simplest route to a web app is PHP.

Certainly there are Python equivalents (mod_python, mod_wsgi, etc.)
which can run in effectively the same way as mod_php, and they could be
configured to run an fcgi frontend script, I presume. There's always a
certain confusion here because you can often one mechanisms (say,
mod_wsgi) to act as another (say legacy one-shot CGI) and because some
things are both mechanism and protocol and it's not always easy to tease
the two apart.


> 
> The reason I ask for all this, is that I want to understand how things
> work under the hood before relying on a Python framework to handle the
> nitty-gritty.

Good scheme.

TJG
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about long-running web scripts

[Gilles]

On Fri, 26 Oct 2012 12:00:17 +0100, Tim Golden 
wrote:
>Certainly there are Python equivalents (mod_python, mod_wsgi, etc.)
>which can run in effectively the same way as mod_php, and they could be
>configured to run an fcgi frontend script, I presume. There's always a
>certain confusion here because you can often one mechanisms (say,
>mod_wsgi) to act as another (say legacy one-shot CGI) and because some
>things are both mechanism and protocol and it's not always easy to tease
>the two apart.

Thanks again.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Quickie - Regexp for a string not at the beginning of the line

[Ben Bacarisse]

Rivka Miller  writes:

> Thanks everyone, esp this gentleman.

Kind of you to single me out, but it was Janis Papanagnou who first
posted the solution that you say "works best" for you.


-- 
Ben.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Quickie - Regexp for a string not at the beginning of the line

[Ed Morton]

On 10/25/2012 11:45 PM, Rivka Miller wrote:

Thanks everyone, esp this gentleman.

The solution that worked best for me is just to use a DOT before the
string as the one at the beginning of the line did not have any char
before it.


That's fine but do you understand that that is not an RE that matches on 
"$hello$ not at the start of a line", it's an RE that matches on "char>$hello$ anywhere in the line"? There's a difference - if you use a tool 
that prints the text that matches an RE then the output if the first RE existed 
would be "$hello$" while the output for the second RE would be "X$hello$" or 
"Y$hello$" or


In some tools you can use /(.)$hello$/ or similar to ignore the first part of 
the RE "(.)" and just print the second "$hello", but that ability and it's 
syntax is tool-specific, you still can't say "here's an RE that does this", 
you've got to say "here's how to find this text using tool ".


   Ed.


I guess, this requires the ability to ignore the CARAT as the beginning of the 
line.

I am a satisfied custormer. No need for returns. :)

On Oct 25, 7:11 pm, Ben Bacarisse  wrote:

Rivka Miller  writes:

On Oct 25, 2:27 pm, Danny  wrote:

Why you just don't give us the string/input, say a line or two, and
what you want off of it, so we can tell better what to suggest



no one has really helped yet.


Really?  I was going to reply but then I saw Janis had given you the
answer.  If it's not the answer, you should just reply saying what it is
that's wrong with it.


I want to search and modify.


Ah.  That was missing from the original post.  You can't expect people
to help with questions that weren't asked!  To replace you will usually
have to capture the single preceding character.  E.g. in sed:

   sed -e 's/\(.\)$hello\$/\1XXX/'

but some RE engines (Perl's, for example) allow you specify zero-width
assertions.  You could, in Perl, write

   s/(?<=.)\$hello\$/XXX/

without having to capture whatever preceded the target string.  But
since Perl also has negative zero-width look-behind you can code your
request even more directly:

   s/(?
I dont wanna be tied to a specific language etc so I just want a
regexp and as many versions as possible. Maybe I should try in emacs
and so I am now posting to emacs groups also, although javascript has
rich set of regexp facilities.


You can't always have a universal solution because different PE
implementations have different syntax and semantics, but you should be
able to translate Janis's solution of matching *something* before your
target into every RE implementation around.


examples



$hello$ should not be selected but
not hello but all of the $hello$ and $hello$ ... $hello$ each one
selected


I have taken your $s to be literal.  That's not 100 obvious since $ is a
common (universal?) RE meta-character.


--
Ben.




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

Re: Quickie - Regexp for a string not at the beginning of the line

[Joel Goldstick]

On Fri, Oct 26, 2012 at 8:32 AM, Ed Morton  wrote:
> On 10/25/2012 11:45 PM, Rivka Miller wrote:
>>
>> Thanks everyone, esp this gentleman.
>>
>> The solution that worked best for me is just to use a DOT before the
>> string as the one at the beginning of the line did not have any char
>> before it.
>
>
> That's fine but do you understand that that is not an RE that matches on
> "$hello$ not at the start of a line", it's an RE that matches on " char>$hello$ anywhere in the line"? There's a difference - if you use a tool
> that prints the text that matches an RE then the output if the first RE
> existed would be "$hello$" while the output for the second RE would be
> "X$hello$" or "Y$hello$" or
>
> In some tools you can use /(.)$hello$/ or similar to ignore the first part
> of the RE "(.)" and just print the second "$hello", but that ability and
> it's syntax is tool-specific, you still can't say "here's an RE that does
> this", you've got to say "here's how to find this text using tool
> ".
>
>Ed.
>
>
>> I guess, this requires the ability to ignore the CARAT as the beginning of
>> the line.
>>
>> I am a satisfied custormer. No need for returns. :)
>>
>> On Oct 25, 7:11 pm, Ben Bacarisse  wrote:
>>>
>>> Rivka Miller  writes:

 On Oct 25, 2:27 pm, Danny  wrote:
>
> Why you just don't give us the string/input, say a line or two, and
> what you want off of it, so we can tell better what to suggest
>>>
>>>
 no one has really helped yet.
>>>
>>>
>>> Really?  I was going to reply but then I saw Janis had given you the
>>> answer.  If it's not the answer, you should just reply saying what it is
>>> that's wrong with it.
>>>
 I want to search and modify.
>>>
>>>
>>> Ah.  That was missing from the original post.  You can't expect people
>>> to help with questions that weren't asked!  To replace you will usually
>>> have to capture the single preceding character.  E.g. in sed:
>>>
>>>sed -e 's/\(.\)$hello\$/\1XXX/'
>>>
>>> but some RE engines (Perl's, for example) allow you specify zero-width
>>> assertions.  You could, in Perl, write
>>>
>>>s/(?<=.)\$hello\$/XXX/
>>>
>>> without having to capture whatever preceded the target string.  But
>>> since Perl also has negative zero-width look-behind you can code your
>>> request even more directly:
>>>
>>>s/(?>>
 I dont wanna be tied to a specific language etc so I just want a
 regexp and as many versions as possible. Maybe I should try in emacs
 and so I am now posting to emacs groups also, although javascript has
 rich set of regexp facilities.
>>>
>>>
>>> You can't always have a universal solution because different PE
>>> implementations have different syntax and semantics, but you should be
>>> able to translate Janis's solution of matching *something* before your
>>> target into every RE implementation around.
>>>
 examples
>>>
>>>
 $hello$ should not be selected but
 not hello but all of the $hello$ and $hello$ ... $hello$ each one
 selected
>>>
>>>
>>> I have taken your $s to be literal.  That's not 100 obvious since $ is a
>>> common (universal?) RE meta-character.
>>>
>>> 
>>> --
>>> Ben.
>>
>>
>
> --
> http://mail.python.org/mailman/listinfo/python-list

I would use str.find('your string')

It returns -1 if not found, and the index if it finds it.

why use regex for this?

-- 
Joel Goldstick
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: bit count or bit set && Python3

[Neil Cerutti]

On 2012-10-25, Ian Kelly  wrote:
> On Thu, Oct 25, 2012 at 2:00 PM, Neil Cerutti
>  wrote:
>> Yes indeed! Python string operations are fast enough and its
>> arithmetic slow enough that I no longer assume I can beat a
>> neat lexicographical solution. Try defeating the following
>> with arithmetic:
>>
>> def is_palindrom(n):
>>s = str(n)
>>return s = s[::-1]
>
> Problems like these are fundamentally string problems, not math
> problems.  The question being asked isn't about some essential
> property of the number,  but about its digital representation.
> Certainly they can be reasoned about mathematically, but the
> fact remains that the math being done is about the properties
> of strings.

The "unexpected" part, to me, is that an optimal arithmetic based
solution conceptually is more efficient. You need to compute just
half the digits of the number and then perform a contant compare
operation.

-- 
Neil Cerutti
-- 
http://mail.python.org/mailman/listinfo/python-list

Escaping from the tedium of naive datetime objects.

[Adam Tauno Williams]

Yesterday I stumbled upon a nice solution to dealing with naive
datetimes vs. localized datetimes, and much of the tedium that issues
from that problem.   Maybe this is very common knownledge but it wasn't
mentioned in anything I've read - it really cleans up some opertaions.




[constructive] Feedback and other suggestions appreciated.

-- 
Adam Tauno Williams 

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

Re: while expression feature proposal

[Dan Loewenherz]

On Thursday, October 25, 2012 11:06:01 PM UTC-7, Paul Rubin wrote:
> Dan Loewenherz  writes:
> 
> > In this case, profile_id is "None" when the loop breaks. It would be
> 
> > much more straightforward (and more Pythonic, IMO), to write:
> 
> >
> 
> > client = StrictRedis()
> 
> > while client.spop("profile_ids") as profile_id:
> 
> > print profile_id
> 
> 
> 
> That is pretty loose, in my opinion.  If the loop is supposed to return
> 
> a string until breaking on None, the break test should explicitly check
> 
> for None rather than rely on an implicit bool conversion that will also
> 
> test as false on an empty string.  Code that handles strings should do
> 
> the right thing with the empty string.  What you posted relies on an
> 
> unstated assumption that the strings that come back are never empty.
> 

I think this is a good point. However, I can't think of any situation where I'd 
want to work with an empty string (in the applications I've worked with, at 
least).

We also don't special case things like this just because x is an empty string. 
If this "while EXPR as VAR" thing were to move forward, we shouldn't treat the 
truth testing any differently than how we already do. IMO we should write our 
applications with the understanding that '' will return False and work with 
that.

Here's a workaround BTW. Just have that method return a tuple, and do the truth 
testing yourself if you feel it's necessary.

while client.spop("profile_ids") as truthy, profile_id:
if not truthy:
break

print profile_id

Here, client.spop returns a tuple, which will always returns true. We then 
extract the first element and run a truth test on it. The function we use is in 
charge of determining the truthiness.

Dan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a.index(float('nan')) fails

[Steven D'Aprano]

On Fri, 26 Oct 2012 03:54:02 -0400, Terry Reedy wrote:

> On 10/25/2012 10:44 PM, Steven D'Aprano wrote:
>> On Thu, 25 Oct 2012 22:04:52 -0400, Terry Reedy wrote:
>>
>>> It is a consequence of the following, which some people (but not all)
>>> believe is mandated by the IEEE standard.
>>>
>>>   >>> nan = float('nan')
>>>   >>> nan is nan
>>> True
>>
>> The IEEE 754 standard says nothing about object identity. It only
>> discusses value equality.
>>
>>>   >>> nan == nan
>>> False
>>
>> IEEE 754 states that all NANs compare unequal to everything, including
>> NANs with the same bit value. It doesn't make an exception for
>> comparisons with itself.
>>
>> I'm not entirely sure why you suggest that there is an argument about
>> what IEEE 754 says about NANs.
> 
> I did not do so.

I'm afraid you did. Your quote is shown above, and repeated here:

"... some people (but not all) believe is mandated by the IEEE standard"

This suggests that there is a disagreement -- an argument -- about what 
the IEEE standard mandates about NANs. I don't know why you think this 
disagreement exists, or who these "some people" are. The standard is not 
ambiguous, and while it is not readily available at no cost, it is widely 
described by many secondary sources.

Every NAN must compare unequal to every float, including itself.


> There has been disagreement about whether the standard mandates that
> Python behave the way it does. That is a fact, but I have no interest in
> discussing the issue.

I'm not entirely sure which behaviour of Python you are referring to 
here. If you choose not to reply, of course I can't force you to. It's 
your right to make ambiguous statements and then refuse to clarify what 
you are talking about.

If you are referring to *identity comparisons*, the IEEE 754 says nothing 
about object identity, so it has no bearing on Python's `is` operator.

If you are referring to the fact that `nan != nan` in Python, that is 
mandated by the IEEE 754 standard. I can't imagine who maintains that the 
standard doesn't mandate that; as I said, the disagreement that I have 
seen is whether or not to follow the standard, not on what the standard 
says.

If you are referring to something else, I don't know what it is.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Ian Kelly]

On Fri, Oct 26, 2012 at 9:29 AM, Dan Loewenherz  wrote:
> while client.spop("profile_ids") as truthy, profile_id:
> if not truthy:
> break
>
> print profile_id
>
> Here, client.spop returns a tuple, which will always returns true. We then 
> extract the first element and run a truth test on it. The function we use is 
> in charge of determining the truthiness.

I don't like the idea of testing the first element.  There's a large
element of surprise in doing that, I think.  I would expect the truth
test to be the same with or without the existence of the "as" clause
there.  That is, you should be able to remove the "as" clause and have
exactly the same behavior, just without the assignments.  So it would
need to test the entire tuple.

That brings up an interesting additional question in my mind, though.
Should the while loop syntax attempt to perform the assignment on the
very last test, when the expression is false?  I think there is a good
argument for doing so, as it will allow additional inspection of the
false value, if necessary.  In the above, though, if the return value
is false (an empty tuple or None) then the assignment would fail
during unpacking, raising an exception.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: bit count or bit set && Python3

[casevh]

On Thursday, October 25, 2012 7:56:25 AM UTC-7, Charles Hixson wrote:
> In Python3 is there any good way to count the number of on bits in an 
> integer (after an & operation)?

You may want to look at gmpy2[1] and the popcount() function.

> 
> Alternatively, is there any VERY light-weight implementation of a bit 
> set?  I'd prefer to use integers, as I'm probably going to need 
> thousands of these, if the tests work out.  But before I can test, I 
> need a decent bit counter.  (shift, xor, &, and | are already present 
> for integer values, but I also need to count the number of "true" items 
> after the logical operation.  So if a bitset is the correct approach, 
> 

Whether or not gmpy2 is considered light-weight is debateable. :)

> I'll need it to implement those operations, or their equivalents in 
> terms of union and intersection.)
> 
> 
> 
> Or do I need to drop into C for this?
> 

[1] http://code.google.com/p/gmpy/

> 
> 
> -- 
> 
> Charles Hixson

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

Re: while expression feature proposal

[Paul Rubin]

Dan Loewenherz  writes:
> We also don't special case things like this just because x is an empty
> string. If this "while EXPR as VAR" thing were to move forward, we
> shouldn't treat the truth testing any differently than how we already
> do. IMO we should write our applications with the understanding that
> '' will return False and work with that.

We don't "already" treat the truth testing any particular way because we
don't have this construction in the language at the moment.  However,
it's well-established in Python that converting a string to a bool
results in False iff the string is empty.

The empty string is a perfectly good string and code that deals with
strings should handle the empty string properly, unless it knows the
string won't be empty.  Basic modularity principles say to avoid putting
such knowledge into more of the code than necessary.  

The conclusion is to not automatically convert the parameter to a bool.
However, if the "as" can be part of an expression as in Chris Angelico's
post, Chris's suggestion

 while (client.spop("profile_ids") as profile_id) is not None:
 print profile_id

looks good to me.

> while client.spop("profile_ids") as truthy, profile_id:
> if not truthy:
> break

This is ugly on two levels.  First of all, if the .spop() still returns
None at the end of the input, the tuple unpacking will fail.  Second,
the separate test and break defeats the purpose of the "while ... as"
construction.  Might as well use the current style of assignment and
test inside the loop.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a.index(float('nan')) fails

[Steven D'Aprano]

On Fri, 26 Oct 2012 04:00:03 -0400, Terry Reedy wrote:

> On 10/25/2012 10:19 PM, MRAB wrote:

>> In summary, .index() looks for an item which is equal to its argument,
>> but it's a feature of NaN (as defined by the standard) that it doesn't
>> equal NaN, therefore .index() will never find it.
> 
> Except that is *does* find the particular nan object that is in the
> collection. So nan in collection and list.index(nan) look for the nan by
> identity, not equality.

So it does. I made the same mistake as MRAB, thank you for the correction.



> This inconsistency is an intentional decision to
> not propagate the insanity of nan != nan to Python collections.

That's a value judgement about NANs which is not shared by everyone.

Quite frankly, I consider it an ignorant opinion about NANs, despite what 
Bertrand Meyer thinks. Reflectivity is an important property, but it is 
not the only important property and it is not even the most important 
property of numbers. There are far worse problems with floats than the 
non-reflexivity of NANs.

Since it is impossible to have a fixed-size numeric type that satisfies 
*all* of the properties of real numbers, some properties must be broken. 
I can only imagine that the reason Meyer, and presumably you, think that 
the loss of reflexivity is more "insane" than the other violations of 
floating point numbers is due to unfamiliarity. (And note that I said 
*numbers*, not NANs.)

Anyone who has used a pocket calculator will be used to floating point 
calculations being wrong, so much so that most people don't even think 
about it. They just expect numeric calculations to be off by a little, 
and don't give it any further thought. But NANs freak them out because 
they're different.

In real life, you are *much* more likely to run into these examples of 
"insanity" of floats than to be troubled by NANs:

- associativity of addition is lost
- distributivity of multiplication is lost
- commutativity of addition is lost
- not all floats have an inverse

e.g. 

(0.1 + 0.2) + 0.3 != 0.1 + (0.2 + 0.3)

1e6*(1.1 + 2.2) != 1e6*1.1 + 1e6*2.2

1e10 + 0.1 + -1e10 != 1e10 + -1e10 + 0.1

1/(1/49.0) != 49.0

Such violations of the rules of real arithmetic aren't even hard to find. 
They're everywhere.

In practical terms, those sorts of errors are *far* more significant in 
computational mathematics than the loss of reflexivity. I can't think of 
the last time I've cared that x is not necessarily equal to x in a 
floating point calculation, but the types of errors shown above are 
*constantly* effecting computations and leading to loss of precision or 
even completely wrong answers.

Once NANs were introduced, keeping reflexivity would lead to even worse 
situations than x != x. It would lead to nonsense identities like 
log(-1) ==log(-2), hence 1 == 2.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: better way for ' '.join(args) + '\n'?

[Hubert Grünheidt]

Hi Ulrich,

is this acceptable?

args = ['foo', 'bar', 'baz']
args.append('\n')
line = ' '.join(args)

Cheers,
  Hubert

On 10/26/2012 09:49 AM, Ulrich Eckhardt wrote:

Hi!

General advise when assembling strings is to not concatenate them
repeatedly but instead use string's join() function, because it avoids
repeated reallocations and is at least as expressive as any alternative.

What I have now is a case where I'm assembling lines of text for driving
a program with a commandline interface. In this scenario, I'm currently
doing this:

   args = ['foo', 'bar', 'baz']
   line = ' '.join(args) + '\n'

So, in other words, I'm avoiding all the unnecessary copying, just to
make another copy to append the final newline.

The only way around this that I found involves creating an intermediate
sequence like ['foo', ' ', 'bar', ' ', 'baz', '\n']. This can be done
rather cleanly with a generator:

   def helper(s):
   for i in s[:-1]:
yield i
yield ' '
   yield s[-1]
   yield '\n'
   line = ''.join(tmp(args))

Efficiency-wise, this is satisfactory. However, readability counts and
that is where this version fails and that is the reason why I'm writing
this message. So, dear fellow Pythonistas, any ideas to improve the
original versions efficiency while preserving its expressiveness?

Oh, for all those that are tempted to tell me that this is not my
bottleneck unless it's called in a very tight loop, you're right.
Indeed, the overhead of the communication channel TCP between the two
programs is by far dwarving the few microseconds I could save here. I'm
still interested in learning new and better solutions though.


Cheers!

Uli



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

Re: bit count or bit set && Python3

[Charles Hixson]

cas...@gmail.com wrote:

On Thursday, October 25, 2012 7:56:25 AM UTC-7, Charles Hixson wrote:

In Python3 is there any good way to count the number of on bits in an
integer (after an&  operation)?

You may want to look at gmpy2[1] and the popcount() function.


Alternatively, is there any VERY light-weight implementation of a bit
set?  I'd prefer to use integers, as I'm probably going to need
thousands of these, if the tests work out.  But before I can test, I
need a decent bit counter.  (shift, xor,&, and | are already present
for integer values, but I also need to count the number of "true" items
after the logical operation.  So if a bitset is the correct approach,


Whether or not gmpy2 is considered light-weight is debateable. :)


I'll need it to implement those operations, or their equivalents in
terms of union and intersection.)



Or do I need to drop into C for this?


[1] http://code.google.com/p/gmpy/



--

Charles Hixson
I can see many times when that would be useful, but for this particular 
case I think that bin(val).count("1") is probably the better solution.  
The other options that I need are already available directly in integer 
numbers, and I will be surprised if I need more than a 32-bit set, so 
integers should be a reasonable approach.  It doesn't seem to have the 
overhead that I feared a string conversion would have (possibly because 
converting an integer to a bit string is trivial),  so I don't think 
that gmpy would add value to this program.


Next I need to decide about weak pointers, and then shelve vs. 
tokyocabinet.  (I sort of don't like shelve, because of its use of 
pickle, with the attendent security risks.  OTOH, the file will be local 
to the computer, not going over the net, which minimizes that.  Still, I 
may decide to reimplement it using ast.literal_eval, as I'm not 
intending to store anything that it won't handle.

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

Re: a.index(float('nan')) fails

[MRAB]

On 2012-10-26 17:23, Steven D'Aprano wrote:

On Fri, 26 Oct 2012 04:00:03 -0400, Terry Reedy wrote:


On 10/25/2012 10:19 PM, MRAB wrote:



In summary, .index() looks for an item which is equal to its argument,
but it's a feature of NaN (as defined by the standard) that it doesn't
equal NaN, therefore .index() will never find it.


Except that is *does* find the particular nan object that is in the
collection. So nan in collection and list.index(nan) look for the nan by
identity, not equality.


So it does. I made the same mistake as MRAB, thank you for the correction.


[snip]
Yes, I forgot that Python checks for identity before checking for
equality:

>>> [float("nan")].index(float("nan"))
Traceback (most recent call last):
  File "", line 1, in 
[float("nan")].index(float("nan"))
ValueError: nan is not in list
>>> nan = float("nan")
>>> [nan].index(nan)
0

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

Re: a.index(float('nan')) fails

[Chris Angelico]

On Sat, Oct 27, 2012 at 3:23 AM, Steven D'Aprano
 wrote:
> In real life, you are *much* more likely to run into these examples of
> "insanity" of floats than to be troubled by NANs:
>
> - associativity of addition is lost
> - distributivity of multiplication is lost
> - commutativity of addition is lost
> - not all floats have an inverse
>
> e.g.
>
> (0.1 + 0.2) + 0.3 != 0.1 + (0.2 + 0.3)
>
> 1e6*(1.1 + 2.2) != 1e6*1.1 + 1e6*2.2
>
> 1e10 + 0.1 + -1e10 != 1e10 + -1e10 + 0.1
>
> 1/(1/49.0) != 49.0
>
> Such violations of the rules of real arithmetic aren't even hard to find.
> They're everywhere.

Actually, as I see it, there's only one principle to take note of: the
"HMS Pinafore Floating Point Rule"...

** Floating point expressions should never be tested for equality **
** What, never? **
** Well, hardly ever! **

The problem isn't with the associativity, it's with the equality
comparison. Replace "x == y" with "abs(x-y)http://mail.python.org/mailman/listinfo/python-list

Recommended way to unpack keyword arguments using **kwargs ?

[Jeff Jeffries]

I have been doing the following to keep my class declarations short:

class MyClass(MyOtherClass):
def __init__(self,*args,**kwargs):
self.MyAttr = kwargs.get('Attribute',None) #To get a default
MyOtherClass.__init__(self,*args,**kwargs)

Is there a recommended way to get keyword arguments (or default) when using
** notation?

-- 
Cheerios,
Jeff Jeffries III
CFO: www.touchmycake.com 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Recommended way to unpack keyword arguments using **kwargs ?

[Ian Kelly]

On Fri, Oct 26, 2012 at 10:58 AM, Jeff Jeffries
 wrote:
> I have been doing the following to keep my class declarations short:
>
> class MyClass(MyOtherClass):
> def __init__(self,*args,**kwargs):
> self.MyAttr = kwargs.get('Attribute',None) #To get a default
> MyOtherClass.__init__(self,*args,**kwargs)
>
> Is there a recommended way to get keyword arguments (or default) when using
> ** notation?

It's better form to use .pop() instead of .get(), as if MyClass is
receiving the argument then MyOtherClass is probably not expecting it.

If using Python 3, you can use the keyword-only argument syntax:

def __init__(self, *args, attribute=None, **kwargs):
# Do something with attribute
MyOtherClass.__init__(self, *args, **kwargs)


Either way, you should really only do this when there are a large
number of possible arguments or you don't really know what arguments
to expect.  When practical to do so, it is preferable to explicitly
list the arguments so that the method signature can be inspected, e.g.
by the help() command.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a.index(float('nan')) fails

[Steven D'Aprano]

On Sat, 27 Oct 2012 03:45:46 +1100, Chris Angelico wrote:

> On Sat, Oct 27, 2012 at 3:23 AM, Steven D'Aprano
>  wrote:
>> In real life, you are *much* more likely to run into these examples of
>> "insanity" of floats than to be troubled by NANs:
>>
>> - associativity of addition is lost
>> - distributivity of multiplication is lost 
>> - commutativity of addition is lost
>> - not all floats have an inverse
>>
>> e.g.
>>
>> (0.1 + 0.2) + 0.3 != 0.1 + (0.2 + 0.3)
>>
>> 1e6*(1.1 + 2.2) != 1e6*1.1 + 1e6*2.2
>>
>> 1e10 + 0.1 + -1e10 != 1e10 + -1e10 + 0.1
>>
>> 1/(1/49.0) != 49.0
>>
>> Such violations of the rules of real arithmetic aren't even hard to
>> find. They're everywhere.
> 
> Actually, as I see it, there's only one principle to take note of: the
> "HMS Pinafore Floating Point Rule"...
> 
> ** Floating point expressions should never be tested for equality ** 
> ** What, never? **
> ** Well, hardly ever! **
> 
> The problem isn't with the associativity, it's with the equality
> comparison. Replace "x == y" with "abs(x-y) and all your statements fulfill people's expectations.

O RYLY?

Would you care to tell us which epsilon they should use?

Hint: *whatever* epsilon you pick, there will be cases where that is 
either stupidly too small, stupidly too large, or one that degenerates to 
float equality. And you may not be able to tell if you have one of those 
cases or not.

Here's a concrete example for you: 

What *single* value of epsilon should you pick such that the following 
two expressions evaluate correctly?

sum([1e20, 0.1, -1e20, 0.1]*1000) == 200
sum([1e20, 99.9, -1e20, 0.1]*1000) != 200


The advice "never test floats for equality" is:

(1) pointless without a good way to know what epsilon they should use;

(2) sheer superstition since there are cases where testing floats for 
equality is the right thing to do (although I note you dodged that bullet 
with "hardly ever" *wink*);

and most importantly

(3) missing the point, since the violations of the rules of real-valued 
mathematics still occur regardless of whether you explicitly test for 
equality or not.

For instance, if you write:

result = a + (b + c)

some compilers may assume associativity and calculate (a + b) + c 
instead. But that is not guaranteed to give the same result! (K&R allowed 
C compilers to do that; the subsequent ANSI C standard prohibited re-
ordering, but in practice most C compilers provide a switch to allow it.)

A real-world example: Python's math.fsum is a high-precision summation 
with error compensation based on the Kahan summation algorithm. Here's a 
pseudo-code version:

http://en.wikipedia.org/wiki/Kahan_summation_algorithm

which includes the steps:

t = sum + y;
c = (t - sum) - y;

A little bit of algebra should tell you that c must equal zero. 
Unfortunately, in this case algebra is wrong, because floats are not real 
numbers. c is not necessarily zero.

An optimizing compiler, or an optimizing programmer, might very well 
eliminate those calculations and so inadvertently eliminate the error 
compensation. And not an equals sign in sight.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a.index(float('nan')) fails

[Terry Reedy]

On 10/26/2012 11:26 AM, Steven D'Aprano wrote:

On Fri, 26 Oct 2012 03:54:02 -0400, Terry Reedy wrote:


On 10/25/2012 10:44 PM, Steven D'Aprano wrote:

On Thu, 25 Oct 2012 22:04:52 -0400, Terry Reedy wrote:


It is a consequence of the following, which some people (but not all)
believe is mandated by the IEEE standard.

   >>> nan = float('nan')
   >>> nan is nan
True


The IEEE 754 standard says nothing about object identity. It only
discusses value equality.


   >>> nan == nan
False


IEEE 754 states that all NANs compare unequal to everything, including
NANs with the same bit value. It doesn't make an exception for
comparisons with itself.

I'm not entirely sure why you suggest that there is an argument about
what IEEE 754 says about NANs.


I did not do so.


I'm afraid you did. Your quote is shown above, and repeated here:


The quote precedes and refers to Python code.



"... some people (but not all) believe is mandated by the IEEE standard"

This suggests that there is a disagreement -- an argument -- about what
the IEEE standard mandates about NANs.


Disagreement about what Python should do has been expressed on the lists 
and even on the tracker. There was one discussion on python-ideas within 
the last month, another a year or so ago.


Python does not implement the full IEEE standard with signalling and 
non-signalling nans and multiple bit patterns.


When a nan is put in a Python collection, it is in effect treated as if 
it were equal to itself.

See the discussion in http://bugs.python.org/issue4296
including "I'm not sure that Python should be asked to guarantee
anything more than "b == b" returning False when b is
a NaN.  It wouldn't seem unreasonable to consider
behavior of nans in containers (sets, lists, dicts)
as undefined when it comes to equality and identity
checks."



--
Terry Jan Reedy

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

[ANN] pypiserver 1.0.0 - minimal private pypi server

[Ralf Schmitt]

Hi,

I've just uploaded pypiserver 1.0.0 to the python package index.

pypiserver is a minimal PyPI compatible server. It can be used to serve
a set of packages and eggs to easy_install or pip.

pypiserver is easy to install (i.e. just 'pip install pypiserver'). It
doesn't have any external dependencies.

http://pypi.python.org/pypi/pypiserver/ should contain enough
information to easily get you started running your own PyPI server in a
few minutes.

The code is available on github: https://github.com/schmir/pypiserver

Changes in version 1.0.0

- add passlib and waitress to pypi-server-standalone
- upgrade bottle to 0.11.3
- Update scripts/opensuse/pypiserver.init
- Refuse to re upload existing file
- Add 'console_scripts' section to 'entry_points', so
  'pypi-server.exe' will be created on Windows.
- paste_app_factory now use the the password_file option to create the
  app. Without this the package upload was not working.
- Add --fallback-url argument to pypi-server script to make it
  configurable.

-- 
Cheers
Ralf
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a.index(float('nan')) fails

[Terry Reedy]

On 10/26/2012 12:23 PM, Steven D'Aprano wrote:

On Fri, 26 Oct 2012 04:00:03 -0400, Terry Reedy wrote:



This inconsistency is an intentional decision to
not propagate the insanity of nan != nan to Python collections.


That's a value judgement about NANs which is not shared by everyone.

Quite frankly, I consider it an ignorant opinion about NANs, despite what
Bertrand Meyer thinks. Reflectivity is an important property, but it is
not the only important property and it is not even the most important
property of numbers.


Reflexivity is one of the definitional properties of the mathematical 
equality relationship and of equivalence relationships in general. It is 
not specific to numbers. It is assumed by the concept and definition of 
sets.


--
Terry Jan Reedy

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

Re: a.index(float('nan')) fails

[Devin Jeanpierre]

On Fri, Oct 26, 2012 at 2:40 PM, Steven D'Aprano
 wrote:
>> The problem isn't with the associativity, it's with the equality
>> comparison. Replace "x == y" with "abs(x-y)> and all your statements fulfill people's expectations.
>
> O RYLY?
>
> Would you care to tell us which epsilon they should use?

I would assume some epsilon that bounds the error of their
computation. Which one to use would depend on the error propagation
their function incurs.

That said, I also disagree with the sentiment "all your statements
fulfill people's expectations". Comparing to be within some epsilon of
each other may mean that some things that are the result of
mathematically unequal expressions, will be called equal because they
are very close to each other by accident. Unless perhaps completely
tight bounds on error can be achieved? I've never seen anyone do this,
but maybe it's reasonable.

> Hint: *whatever* epsilon you pick, there will be cases where that is
> either stupidly too small, stupidly too large, or one that degenerates to
> float equality. And you may not be able to tell if you have one of those
> cases or not.
>
> Here's a concrete example for you:
>
> What *single* value of epsilon should you pick such that the following
> two expressions evaluate correctly?
>
> sum([1e20, 0.1, -1e20, 0.1]*1000) == 200
> sum([1e20, 99.9, -1e20, 0.1]*1000) != 200

Some computations have unbounded error, such as computations where
catastrophic cancellation can occur. That doesn't mean all
computations do. For many computations, you can find a single epsilon
that will always return True for things that "should" be equal, but
aren't -- for example, squaring a number does no worse than tripling
the relative error, so if you square a number that was accurate to
within machine epsilon, and want to compare it to a constant, you can
compare with relative epsilon = 3*machine_epsilon.

I'm not sure how commonly this occurs in real life, because I'm not a
numerical programmer. All I know is that your example is good, but
shows a not-universally-applicable problem.

It is, however, still pretty applicable and worth noting, so I'm not
unhappy you did. For example, how large can the absolute error of the
sin function applied to a float be? Answer: as large as 2, and the
relative error can be arbitrarily large. (Reason: error scales with
the input, but the frequency of the sin function does not.)

(In case you can't tell, I only have studied this stuff as a student. :P)

-- Devin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: better way for ' '.join(args) + '\n'?

[Tycho Andersen]

On Fri, Oct 26, 2012 at 09:49:50AM +0200, Ulrich Eckhardt wrote:
> Hi!
> 
> General advise when assembling strings is to not concatenate them
> repeatedly but instead use string's join() function, because it
> avoids repeated reallocations and is at least as expressive as any
> alternative.
> 
> What I have now is a case where I'm assembling lines of text for
> driving a program with a commandline interface. In this scenario,
> I'm currently doing this:
> 
>   args = ['foo', 'bar', 'baz']
>   line = ' '.join(args) + '\n'

Assuming it's the length of the list that's the problem, not the
length of the strings in the list...

args = ['foo', 'bar', 'baz']
args[-1] = args[-1] + '\n'
line = ' '.join(args)

\t
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: better way for ' '.join(args) + '\n'?

[Dave Angel]

On 10/26/2012 05:26 PM, Tycho Andersen wrote:
> On Fri, Oct 26, 2012 at 09:49:50AM +0200, Ulrich Eckhardt wrote:
>> Hi!
>>
>> General advise when assembling strings is to not concatenate them
>> repeatedly but instead use string's join() function, because it
>> avoids repeated reallocations and is at least as expressive as any
>> alternative.
>>
>> What I have now is a case where I'm assembling lines of text for
>> driving a program with a commandline interface. In this scenario,
>> I'm currently doing this:
>>
>>   args = ['foo', 'bar', 'baz']
>>   line = ' '.join(args) + '\n'
> Assuming it's the length of the list that's the problem, not the
> length of the strings in the list...
>
> args = ['foo', 'bar', 'baz']
> args[-1] = args[-1] + '\n'
> line = ' '.join(args)
>
> \t

Main problem with that is the trailing space before the newline.  If
that's not a problem, then fine.

Not sure why we try so hard to optimize something that's going to take
negligible time.

-- 

DaveA

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

Re: better way for ' '.join(args) + '\n'?

[Tycho Andersen]

On Fri, Oct 26, 2012 at 05:36:50PM -0400, Dave Angel wrote:
> On 10/26/2012 05:26 PM, Tycho Andersen wrote:
> > Assuming it's the length of the list that's the problem, not the
> > length of the strings in the list...
> >
> > args = ['foo', 'bar', 'baz']
> > args[-1] = args[-1] + '\n'
> > line = ' '.join(args)
> >
> > \t
> 
> Main problem with that is the trailing space before the newline.  If
> that's not a problem, then fine.

What trailing space before the newline? The other solutions have it,
the above does not. However, the above does mutate args, which isn't
all that great. Alas, if you want the performance of mutable
structures, you're probably going to have to mutate something. (In any
case, it's easy enough to change it back, though ugly.)

> Not sure why we try so hard to optimize something that's going to take
> negligible time.

The same reason some people enjoy sporting events: it's fun :-)

\t
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to set 250000 baud rate in pyserial ?

[kurabas]

Error is like cannot set special baud rate.
But as I said pyserial set this speed without problem  for ttyUSB0
So it seems pyserial uses diefferent code depending of port type.
I tried to simlink ln -s ttyACM0 ttyUSB0 but it does not work


On Thursday, October 25, 2012 9:11:23 PM UTC+3, Dennis Lee Bieber wrote:
> On Thu, 25 Oct 2012 04:09:56 -0700 (PDT), kura...@gmail.com declaimed
> 
> the following in gmane.comp.python.general:
> 
> 
> 
> > I use Arduino 1280 and Arduino 2560 under Fedora 15. 
> 
> > 1280 creates ttyUSB0 port  and can be set at 250 successfully.
> 
> > 2560 creates ttyACM0 port and can be only set at speeds from list (no 
> > 25) in pyserial. How to set 25 to ttyACM0 port?? Need I patch 
> > kernel or python?
> 
> 
> 
>   You don't say what error you are receiving but looking at the source
> 
> (serialposix.py) implies that it accepts nearly anything on Linux, and
> 
> relies on the OS returning a success/failure if the value is allowed or
> 
> not. 
> 
> 
> 
>   xxxBSD, SunOS, HPUX, IRIX, and CYGWIN systems don't allow "special"
> 
> baudrates at all.
> 
> 
> 
>   .NET, JVM, and Windows don't seem to have explicit call outs for bad
> 
> rates -- just a generic port configured OK test.
> 
> -- 
> 
>   Wulfraed Dennis Lee Bieber AF6VN
> 
> wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/

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

Re: while expression feature proposal

[Cameron Simpson]

On 26Oct2012 09:10, Paul Rubin  wrote:
| However, if the "as" can be part of an expression as in Chris Angelico's
| post, Chris's suggestion
| 
|  while (client.spop("profile_ids") as profile_id) is not None:
|  print profile_id
| 
| looks good to me.

Now this pulls me from a -0 to a +0.5.

Instead of burdening the control constructs with further structure, make
"as" a binding operation for keeping intermediate results from expressions.

It will work anywhere an expression is allowed, and superficially
doesn't break stuff that exists if "as" has the lowest precedence.

Any doco would need to make it clear that no order of operation is
implied, so that this:

  x = 1
  y = (2 as x) + x

does not have a defined answer; might be 2, might be 3. Just like any
other function call with side effects.

Speaking for myself (of course!), I definitely prefer this to adding
"as" as a post expression struction on if/while/etc.

I'm not +1 because to my mind it still presents a way for
assignment/binding to not be glaringly obvious at the left hand side of
an expression.

It would probably mean folding the except/with "as" uses back into
expressions and out of the control-structural part of the grammar. I can't
see that that would actually break any existing code though - anyone else?

Cheers,
-- 
Cameron Simpson 

UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things.   - Doug Gwyn
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to set 250000 baud rate in pyserial ?

[Michael Torrie]

On 10/26/2012 04:01 PM, kura...@gmail.com wrote:
> Error is like cannot set special baud rate. But as I said pyserial
> set this speed without problem  for ttyUSB0 So it seems pyserial uses
> diefferent code depending of port type. I tried to simlink ln -s
> ttyACM0 ttyUSB0 but it does not work

No the difference in how baud rate is set is most likely in the driver.
 pyserial just uses standard kernel apis and ioctls to control the device.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Ian Kelly]

On Fri, Oct 26, 2012 at 4:03 PM, Cameron Simpson  wrote:
> It will work anywhere an expression is allowed, and superficially
> doesn't break stuff that exists if "as" has the lowest precedence.

Please, no.  There is no need for it outside of while expressions, and
anywhere else it's just going to be bad practice.  Even if it's
considered an expression, let's only allow it in while expressions.

> Any doco would need to make it clear that no order of operation is
> implied, so that this:
>
>   x = 1
>   y = (2 as x) + x
>
> does not have a defined answer; might be 2, might be 3. Just like any
> other function call with side effects.

Actually, the docs are clear that expressions are evaluated left to
right, so the expected result of the above would be 4.

> It would probably mean folding the except/with "as" uses back into
> expressions and out of the control-structural part of the grammar. I can't
> see that that would actually break any existing code though - anyone else?

Yes it would, because the meaning is a bit different in both of those
cases.  For except, the result of the expression (an exception class
or tuple of classes) is not stored in the target; the exception
*instance* is.  Similarly for with, the result of the expression is
not stored; the result of calling its __enter__ method is, which is
often but not always the same thing.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Devin Jeanpierre]

On Fri, Oct 26, 2012 at 1:12 AM, Dan Loewenherz  wrote:
> It seems the topic of this thread has changed drastically from the original 
> message.
>
> 1) "while EXPR as VAR" in no way says that EXPR must be a boolean value. In 
> fact, a use case I've run into commonly in web development is popping from a 
> redis set. E.g.
>
> client = StrictRedis()
> while True:
> profile_id = client.spop("profile_ids")
> if not profile_id:
> break
> print profile_id
>
> In this case, profile_id is "None" when the loop breaks. It would be much 
> more straightforward (and more Pythonic, IMO), to write:
>
> client = StrictRedis()
> while client.spop("profile_ids") as profile_id:
> print profile_id

For loops are pythonic. You can do this in Python today:

client = StrictRedis()
for profile_id in iter(lambda: client.spop("profile_ids"), None):
pass

I would like a better iter(), rather than a better while loop. It is
irritating to pass in functions that take arguments, and it is
impossible to, say, pass in functions that should stop being iterated
over when they return _either_ a None or a, say, False.

-- Devin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Devin Jeanpierre]

On Fri, Oct 26, 2012 at 2:23 AM, Chris Angelico  wrote:
> while (client.spop("profile_ids") as profile_id) is not None:
> print profile_id
>
> Why is everyone skirting around C-style assignment expressions as
> though they're simultaneously anathema and the goal? :)

Why should these two statements behave differently? :(

with foo() as bar: bar.baz()
with (foo() as bar): bar.baz()

I don't understand why everyone is so attached to this "as" syntax.
It's confusing because it behaves subtly differently than how it works
in "with", and it puts the variable on the wrong side of the
assignment operator.

(I've always been partial to ":=", personally.)

-- Devin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Tim Chase]

On 10/26/12 17:03, Cameron Simpson wrote:
> On 26Oct2012 09:10, Paul Rubin  wrote:
> |  while (client.spop("profile_ids") as profile_id) is not None:
> 
> Now this pulls me from a -0 to a +0.5.
> 
> Any doco would need to make it clear that no order of operation is
> implied, so that this:
> 
>   x = 1
>   y = (2 as x) + x
> 
> does not have a defined answer; might be 2, might be 3. Just like any
> other function call with side effects.

I really don't like undefined (or underdefined) specs.  If it was to
be PEP'd out, I'd want to address as many edge cases as possible.
Such as

  y = (2 as x) + (3 as x) + (4 as x)
  y = (2 as x) + 4 as x
  y = booleanish and (2 as x) or (4 as x)
  y = booleanish and 2 or 4 as x
  y = (2 as x) if booleanish else (3 as x)
  y = (2 as x) if booleanish else (3 as z)

regardless of how "$PEJORATIVE, that's a dumb thing to do!" it is.

I hate C for how underdefined a lot of corners are. ("amongst my
hatreds of C are such diverse elements as: underdefined corners, a
pitiful standard library, the ease of shooting yourself in the foot,
...")

> I'm not +1 because to my mind it still presents a way for
> assignment/binding to not be glaringly obvious at the left hand side of
> an expression.

I think this is why I like it in the "while" (and could be twisted
into accepting it for "if") because it also introduces an
implied/actual scope for which the variable is intended.  In an
arbitrary evaluation/assignment, it's much easier to lose the
"definition" nature of it at the top of a block.

-tkc





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

Re: SSH Connection with Python

[Gelonida N]

On 10/25/2012 12:47 PM, Kamlesh Mutha wrote:

You can use paramiko module. Very easy to use.




I also use paramiko for a small script.

However I'm a little hesitant to use paramik for new code.

The web page says: "last updated 21-May-2011"

and the github url  http://github.com/robey/paramiko/
yields me a 404

However I didn't really find any alternative.
For cross platform scripts  (Linux / windows)
subprocess is not such a good alternative.


Another problem is, that paramiko depends on pycrypto 2.1+
which doesn't exist as binary release for python 2.7


Is fabric capable of performing scp / sftp

Is there any other library as alternative?

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

Re: while expression feature proposal

[Dan Loewenherz]

On Fri, Oct 26, 2012 at 4:12 PM, Devin Jeanpierre wrote:

>
> For loops are pythonic. You can do this in Python today:
>
> client = StrictRedis()
> for profile_id in iter(lambda: client.spop("profile_ids"), None):
> pass
>
> I would like a better iter(), rather than a better while loop. It is
> irritating to pass in functions that take arguments, and it is
> impossible to, say, pass in functions that should stop being iterated
> over when they return _either_ a None or a, say, False.
>

You can kind of do this by creating a class implementing __eq__ and passing
that in as the sentinal to the iter method.

class FlexibleEquality(object):
def __init__(self, *candidates):
self.candidates = candidates

def __eq__(self, other):
return any(other == candidate for candidate in self.candidates)

client = StrictRedis()
for profile_id in iter(lambda: client.spop("profile_ids"),
FlexibleEquality(False, None)):
pass

But this is yucky. I'd much rather have something a bit more clear to the
reader. The above is somewhat convoluted. I would far prefer for "while
EXPR as VAR" to run through the results of EXPR as an iterable and continue
the loop if any of the values in the iterable is truthy, maybe passing only
the first value of the iterable to VAR. Gives maximum flexibility with the
cleanest resulting code.

>>> client.spop("profile_ids") # conditional succeeds, '123' passed to
profile_id
'123', True
>>> client.spop("profile_ids") # conditional succeeds, '' passed to
profile_id
'', True
>>> client.spop("profile_ids") # conditional fails
'', False

Dan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Devin Jeanpierre]

On Fri, Oct 26, 2012 at 6:03 PM, Cameron Simpson  wrote:
> Any doco would need to make it clear that no order of operation is
> implied, so that this:
>
>   x = 1
>   y = (2 as x) + x
>
> does not have a defined answer; might be 2, might be 3. Just like any
> other function call with side effects.

But function calls with side effects _do_ have a defined order of
evaluation. Left to right. And the answer should be 4.

http://docs.python.org/reference/expressions.html#evaluation-order

>>> def set_(d, k, v):
... d[k] = v
... return v
...
>>> d = {}
>>> set_(d, 'x', 1)
1
>>> set_(d, 'y', set_(d, 'x', 2) + d['x'])
4

-- Devin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Cameron Simpson]

On 26Oct2012 19:41, Devin Jeanpierre  wrote:
| On Fri, Oct 26, 2012 at 6:03 PM, Cameron Simpson  wrote:
| > Any doco would need to make it clear that no order of operation is
| > implied, so that this:
| >
| >   x = 1
| >   y = (2 as x) + x
| >
| > does not have a defined answer; might be 2, might be 3. Just like any
| > other function call with side effects.
| 
| But function calls with side effects _do_ have a defined order of
| evaluation. Left to right.
| And the answer should be 4.
| http://docs.python.org/reference/expressions.html#evaluation-order

No. Separate _expressions_ are evaluated left to right.

So this:

  f(1), f(2)

calls "f(1)" first, then "f(2)". But this:

  f(1) + f(2)

need not do so. Counter-documentation welcomed, but the doco you cite
does not define an order for the second example above.

| 
| >>> def set_(d, k, v):
| ... d[k] = v
| ... return v
| ...
| >>> d = {}
| >>> set_(d, 'x', 1)
| 1
| >>> set_(d, 'y', set_(d, 'x', 2) + d['x'])
| 4

That may just be a coincidence of implementation - there's no special
reason to change the evaluation order form the lexical order there, but
expression optimisers should have a free hand generally.

Cheers,
-- 
Cameron Simpson 

Acceptance Testing: Dropping your mods straight into the production
environment to see if the users will accept them.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Devin Jeanpierre]

On Fri, Oct 26, 2012 at 7:41 PM, Dan Loewenherz  wrote:
-- snip insanity --
>
> But this is yucky. I'd much rather have something a bit more clear to the
> reader.

That's why I said I wanted a better iter, not some equality-overriding
object strawman thing.

I was thinking more like this:

for profile_id in iter(None)(client.spop, "profile_ids"):

or alternatively:

for profile_id in iter(bool)(client.spop, "profile_ids"):

Or perhaps either as keyword arguments (which is the only reason I
curried iter).

The interesting case for in-place assignment is not here. This is a
trivial case. It's in cases like this:

while True:
x = foo(bar())
if x is None: break
if x % 2 == 0: break

print x

Imagine doing that with iter. :)

-- Devin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Devin Jeanpierre]

On Fri, Oct 26, 2012 at 7:56 PM, Cameron Simpson  wrote:
> No. Separate _expressions_ are evaluated left to right.
>
> So this:
>
>   f(1), f(2)
>
> calls "f(1)" first, then "f(2)". But this:
>
>   f(1) + f(2)
>
> need not do so. Counter-documentation welcomed, but the doco you cite
> does not define an order for the second example above.

Actually, it does. Both f(1) and f(2) are separate (sub-)expressions
in f(1) + f(2). More to the point, it gives the following example:

In the following lines, expressions will be evaluated in the
arithmetic order of their suffixes:
...
expr1 + expr2 * (expr3 - expr4)

I sympathize with your concern, though. Order of evaluation is very
bitey, and it's better to be safe than sorry.

-- Devin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Cameron Simpson]

On 26Oct2012 18:26, Tim Chase  wrote:
| On 10/26/12 17:03, Cameron Simpson wrote:
| > On 26Oct2012 09:10, Paul Rubin  wrote:
| > |  while (client.spop("profile_ids") as profile_id) is not None:
| > 
| > Now this pulls me from a -0 to a +0.5.
| > 
| > Any doco would need to make it clear that no order of operation is
| > implied, so that this:
| > 
| >   x = 1
| >   y = (2 as x) + x
| > 
| > does not have a defined answer; might be 2, might be 3. Just like any
| > other function call with side effects.
| 
| I really don't like undefined (or underdefined) specs.  If it was to
| be PEP'd out, I'd want to address as many edge cases as possible.

I would not. Big time. One of the reasons C is so successful as a
lower level language is that by defining only what is needed to be
defined to make it _possible_ to get predictable and useful behaviour,
maximum flexibility is left for implementation to adapt to particular
environments as freely as possible.

Pinning down all the corner cases is in general a bad idea, IMO. Every
corner case you pin down is an early decision for inflexibility that may
later prove to be illfounded.

Specify what _needs_ to be specified to achieve the required effect.
And stay the hell away from things that only constraint outcomes while
not providing the required effect.

To take an obvious counter example: your stance would encourage defining
the iteration order of dictionary keys. To no good purpose, merely to
present definition of _all_ operations instead of just the necessary
operations.

| Such as
|   y = (2 as x) + (3 as x) + (4 as x)
|   y = (2 as x) + 4 as x

I would want these to be ambiguous, myself.

|   y = booleanish and (2 as x) or (4 as x)
|   y = booleanish and 2 or 4 as x
|   y = (2 as x) if booleanish else (3 as x)
|   y = (2 as x) if booleanish else (3 as z)

None of these is ambiguous. The second one could be harder to read and
want some brackets purely for clarity, but it is perfectly well defined
in outcome already.

| regardless of how "$PEJORATIVE, that's a dumb thing to do!" it is.

No, sometimes dumb things should remain bad ideas. Defining them to all
just makes them no longer obviously bad ideas, merely subtly bad ideas.
And subtly bad ideas are worse!

| I hate C for how underdefined a lot of corners are. ("amongst my
| hatreds of C are such diverse elements as: underdefined corners, a
| pitiful standard library, the ease of shooting yourself in the foot,
| ...")

The C standard library was pretty good for when it came out. And the higher
up the available facilities tree you go the more choices there are about
how something should be done. C is still one of my favourite languages
in its domain, though I haven't used it much for several years.

If you're uncomfortable with C, try to stay away from it. (I try to stay
away from C++ and its bretheren for similar reasons.)

| > I'm not +1 because to my mind it still presents a way for
| > assignment/binding to not be glaringly obvious at the left hand side of
| > an expression.
| 
| I think this is why I like it in the "while" (and could be twisted
| into accepting it for "if") because it also introduces an
| implied/actual scope for which the variable is intended.

A conceptual scope, sure. Presumably not a real one in Python...

| In an
| arbitrary evaluation/assignment, it's much easier to lose the
| "definition" nature of it at the top of a block.

I'm not sure I agree here. Code example?

Cheers,
-- 
Cameron Simpson 

Everything should be made as simple as possible, but no simpler.
- Albert Einstein
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Cameron Simpson]

On 27Oct2012 10:56, I wrote:
| On 26Oct2012 19:41, Devin Jeanpierre  wrote:
| | But function calls with side effects _do_ have a defined order of
| | evaluation. Left to right.
| | And the answer should be 4.
| | http://docs.python.org/reference/expressions.html#evaluation-order
| 
| No. Separate _expressions_ are evaluated left to right.
[...]
| need not do so. Counter-documentation welcomed, but the doco you cite
| does not define an order for the second example above.
[...]

On 26Oct2012 16:48, Ian Kelly  wrote:
| > does not have a defined answer; might be 2, might be 3. Just like any
| > other function call with side effects.
| Actually, the docs are clear that expressions are evaluated left to
| right, so the expected result of the above would be 4.

Ian, Devin, my apologies. You're right, the docs are clear and my brain
is foggy. So, no ambiguity about that with the suggested "as" operator.
-- 
Cameron Simpson 

Well, if you didn't struggle so much, you wouldn't get rope burns.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Cameron Simpson]

On 26Oct2012 16:48, Ian Kelly  wrote:
| On Fri, Oct 26, 2012 at 4:03 PM, Cameron Simpson  wrote:
| > It will work anywhere an expression is allowed, and superficially
| > doesn't break stuff that exists if "as" has the lowest precedence.
| 
| Please, no.  There is no need for it outside of while expressions, and
| anywhere else it's just going to be bad practice.  Even if it's
| considered an expression, let's only allow it in while expressions.

We might just have to differ here.

| > It would probably mean folding the except/with "as" uses back into
| > expressions and out of the control-structural part of the grammar. I can't
| > see that that would actually break any existing code though - anyone else?
| 
| Yes it would, because the meaning is a bit different in both of those
| cases.  For except, the result of the expression (an exception class
| or tuple of classes) is not stored in the target; the exception
| *instance* is.  Similarly for with, the result of the expression is
| not stored; the result of calling its __enter__ method is, which is
| often but not always the same thing.

Hmm. Good points. Possibly damning points.

  except (E1, E2) as c as d:

anyone? I should hope not!

I may be back to +0 now:-( +0.5 for being able to get at partial
expression results somehow, -0.1 for the conflict above.

Cheers,
-- 
Cameron Simpson 

Every \item command in item_list must have an optional argument.
- Leslie Lamport, LaTeX
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Steven D'Aprano]

On Fri, 26 Oct 2012 19:12:17 -0400, Devin Jeanpierre wrote:

> I would like a better iter(), rather than a better while loop. It is
> irritating to pass in functions that take arguments, and it is
> impossible to, say, pass in functions that should stop being iterated
> over when they return _either_ a None or a, say, False.

Write a trivial helper function. Not everything has to be a one-liner or 
a built-in.

def iterate_until_none_or_false(func, *args, **kwargs):
while True:
x = func(*args, **kwargs)
# Halt if x is None or False, but not other falsey values.
if x is None or x is False:
return
yield x

for x in iterate_until_none_or_false(
some_function, 1, 2, "c", spam="yummy"):
process(x)



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Cameron Simpson]

On 26Oct2012 19:19, Devin Jeanpierre  wrote:
| (I've always been partial to ":=", personally.)

I'm less so. It is hard to type (on my keyboard anyway, that's a shifted
keystroke followed by an unshifted one). I mank that up often enough
that I would resent it for something as oft used as an assignment.

Visually, yes, it's good. I was happy with it in Pascal and its like,
though I find the succinctness of plain "=" very attractive given that
it is only available on the left in Python, where it is easy to see and
not prone to mixups with == later in an expression.

Cheers,
-- 
Cameron Simpson 

George, discussing a patent and prior art:
"Look, this  publication has a date, the patent has a priority date,
can't you just compare them?"
Paul Sutcliffe:
"Not unless you're a lawyer."
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: SSH Connection with Python

[Roy Smith]

In article ,
 Gelonida N  wrote:

> Another problem is, that paramiko depends on pycrypto 2.1+
> which doesn't exist as binary release for python 2.7

I'm running paramiko-1.7.6 with python 2.7.3 on my Ubunto Precise box.  
I'm reasonably sure all I did was "pip install paramiko".

On the other hand, it may have built it from source during the install.  
Generally, I just let pip do it's magic and don't worry about the 
details.  If you're in an environment where you don't have the compiler 
tool chain, you may be more constrained.

> Is fabric capable of performing scp / sftp

Fabric uses ssh to make connections, and it is capable of copying files.  
For all intents and purposes, I'd say that means it is capable of 
"performing scp / sftp" (both of which are just front-ends to the same 
basic ssh protocol.

But, keep in mind that fabric depends on paramiko.  If you can't get 
paramiko installed, you probably can't get fabric either.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Devin Jeanpierre]

On Fri, Oct 26, 2012 at 8:18 PM, Steven D'Aprano
 wrote:
>> I would like a better iter(), rather than a better while loop. It is
>> irritating to pass in functions that take arguments, and it is
>> impossible to, say, pass in functions that should stop being iterated
>> over when they return _either_ a None or a, say, False.
>
> Write a trivial helper function. Not everything has to be a one-liner or
> a built-in.

You are missing the point. I was suggesting that the use case of new
syntax might be satisfied instead by new functions, which are clearly
preferable to new syntax from the perspective your rebuttal comes
from.

Indeed, one could write those helper functions, and use them, without
any changes to Python being made at all!

-- Devin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: while expression feature proposal

[Chris Angelico]

On Sat, Oct 27, 2012 at 10:19 AM, Devin Jeanpierre
 wrote:
> On Fri, Oct 26, 2012 at 2:23 AM, Chris Angelico  wrote:
>> while (client.spop("profile_ids") as profile_id) is not None:
>> print profile_id
>>
>> Why is everyone skirting around C-style assignment expressions as
>> though they're simultaneously anathema and the goal? :)
>
> Why should these two statements behave differently? :(
>
> with foo() as bar: bar.baz()
> with (foo() as bar): bar.baz()
>
> I don't understand why everyone is so attached to this "as" syntax.
> It's confusing because it behaves subtly differently than how it works
> in "with", and it puts the variable on the wrong side of the
> assignment operator.
>
> (I've always been partial to ":=", personally.)

I'm not attached to "as", myself. It puts the variable at the wrong
end, and feels backward compared to a convention that exists elsewhere
in the language (regular variable assignment). This is a much stronger
backwardness issue than the Python ternary operator (which is only
backward in comparison to other languages).

Personally, I'm quite happy with assignment itself being an
expression. But since that's unlikely to be directly accepted in
Python, I would be looking for something as general as possible -
something that can truly be used _anywhere_ - rather than a specific
while-statement enhancement. Capturing partial expression results is
an extremely convenient thing to do.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

how to change os.popen4 to subprocess

[skyworld]

Hi,

I'm new to python and I'm trying to porting some scripts from v0.96 to
v2.0.1. A piece of code is like this:

cmd_h = os.popen4(env['SYSCMDLINE'])[1]

the system indicates the popen4 is deprecated and suggest to use
subprocess. Can anybody tell me how to use subprocess in this case?
and what does "[1]" here means?

thanks.
-- 
http://mail.python.org/mailman/listinfo/python-list

attaching names to subexpressions

[Steve Howell]

I have been reading the thread "while expression feature proposal,"
and one of the interesting outcomes of the thread is the idea that
Python could allow you to attach names to subexpressions, much like C
allows.  In C you can say something like this:

  tax_next_year = (new_salary = salary * (1 + raise)) * tax_rate

To avoid the "=" pitfall, folks have proposed something like this for
Python:

  tax_next_year = ((salary * (1 + raise)) as new_salary) * tax_rate
  print new_salary, tax_next_year

The basic rule in Python is that you can only do one assignment per
line of code, which generally forces you to write more readable code
IMHO:

  new_salary = salary * (1 + raise)
  tax_next_year = new_salary * tax_rate
  print new_salary, tax_next_year

The above code is slightly more verbose than the "as" proposal would
permit, but the latter code is arguably easier for a human to parse,
and it's also very amenable to print debugging and/or defensive
coding:

  new_salary = salary * (1 + raise)
  print new_salary
  assert new_salary > salary
  tax_next_year = new_salary * tax_rate
  print new_salary, tax_next_year

If the problem statement is "How do I name subexpression?", then
Python already has a clear path--break your code up into multiple
lines.  I'm wondering where this simple solution really breaks down
from a readability perspective.  Perhaps with short-circuited boolean
expressions?






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

Re: how to change os.popen4 to subprocess

[MRAB]

On 2012-10-27 03:28, skyworld wrote:

Hi,

I'm new to python and I'm trying to porting some scripts from v0.96 to
v2.0.1. A piece of code is like this:

cmd_h = os.popen4(env['SYSCMDLINE'])[1]

the system indicates the popen4 is deprecated and suggest to use
subprocess. Can anybody tell me how to use subprocess in this case?
and what does "[1]" here means?


os.popen4 returns a tuple of (child_stdin, child_stdout_and_stderr).
The [1] gets the child_stdout_and_stderr member.

Using the subprocess module:

# Untested!
cmd_h = subprocess.Popen(env['SYSCMDLINE'], stdout=subprocess.PIPE, 
stderr=subprocess.STDOUT, shell=True).stdout


Explanation:

The command line: env['SYSCMDLINE']

Return stdout: stdout=subprocess.PIPE

stderr should be combined with stdout: stderr=subprocess.STDOUT

Let the shell parse the command line: shell=True

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

Re: how to change os.popen4 to subprocess

[Mark Lawrence]

On 27/10/2012 03:28, skyworld wrote:

Hi,

I'm new to python and I'm trying to porting some scripts from v0.96 to
v2.0.1. A piece of code is like this:


What software are you talking about here, it's certainly not Python 
versions as the most up to date are 2.7.3 and 3.3.0?




cmd_h = os.popen4(env['SYSCMDLINE'])[1]

the system indicates the popen4 is deprecated and suggest to use
subprocess. Can anybody tell me how to use subprocess in this case?
and what does "[1]" here means?


If you don't know what the [1] means you've got problems :)  I suggest 
you read the tutorial here first 
http://docs.python.org/tutorial/index.html then the subprocess module 
here http://docs.python.org/library/subprocess.html#module-subprocess, 
specifically 
http://docs.python.org/library/subprocess.html#subprocess-replacements




thanks.



No problem.

--
Cheers.

Mark Lawrence.

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

Re: while expression feature proposal

[Paul Rubin]

Steven D'Aprano  writes:
> There's no need for it *inside* of while expressions. It doesn't add to 
> the expressiveness of the language, or increase the power of the 
> language, or help people write correct code. It saves one trivial line of 
> code in some, but not all, while loops, at the cost of increasing the 
> complexity of the language and parser.

I'm maybe +0.25 on the suggestion but it does save more than one line in
the places where it's useful, plus improves clarity.  You get to write
 
   while (foo() as x) is not None:
   ...

instead of

  while True:
x = foo()
if x is not None:
   break
...

which is much uglier.  Maybe there are even times when you want

   while (left() as x) != (right() as y): ...

that is even messier when expanded out.

There was also the cascaded regexp match example, that happens regularly
in real code and that I've hacked various workarounds for, or wished for
a Maybe monad.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to change os.popen4 to subprocess

[skyworld]

On Oct 27, 11:02 am, MRAB  wrote:
> On 2012-10-27 03:28, skyworld wrote:> Hi,
>
> > I'm new to python and I'm trying to porting some scripts from v0.96 to
> > v2.0.1. A piece of code is like this:
>
> > cmd_h = os.popen4(env['SYSCMDLINE'])[1]
>
> > the system indicates the popen4 is deprecated and suggest to use
> > subprocess. Can anybody tell me how to use subprocess in this case?
> > and what does "[1]" here means?
>
> os.popen4 returns a tuple of (child_stdin, child_stdout_and_stderr).
> The [1] gets the child_stdout_and_stderr member.
>
> Using the subprocess module:
>
> # Untested!
> cmd_h = subprocess.Popen(env['SYSCMDLINE'], stdout=subprocess.PIPE,
> stderr=subprocess.STDOUT, shell=True).stdout
>
> Explanation:
>
> The command line: env['SYSCMDLINE']
>
> Return stdout: stdout=subprocess.PIPE
>
> stderr should be combined with stdout: stderr=subprocess.STDOUT
>
> Let the shell parse the command line: shell=True

thanks
-- 
http://mail.python.org/mailman/listinfo/python-list