Re: Varable parsing error with python

[Chris Angelico]

On Tue, Feb 10, 2015 at 6:30 PM, OmPs  wrote:
> def _getPackgeVersion(xmlfile, p):
> package = str(p)
> if isinstance(fpmdict["application"]["package"], list):
> for i in fpmdict["application"]["package"]:
> if i["@name"] == p:
> _pkgVersion = i["version"]
> else:
> _pkgversion = fpmdict["application"]["package"]["version"]
> return _pkgVersion

One of your branches doesn't have a return statement in it, so Python
just returns None. You may want to unindent that return statement one
level.

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

Varable parsing error with python

[OmPs]

In an XML file which contain a tag and then these tags contain properties,
which later are being called in anoter tag where these properties are
expanded as variables.

For eg.









  

 1.0

  







 1.2

  Red Hat Enterprise Linux Server 5 X86_64

  testsapppath









 my testapp area

 ${APPVERSION}





So now i have written a python program whcih is parsing this program, so
what i am doing in here is reading this xml file



with open(filename, "r") as f:

orig_xml = f.read()

#unescape html characters like %20

xmlstring = urllib.unquote(orig_xml)

#convert xml to dict

doc = xmltodict.parse(xmlstring)

#replace property values in xml string via instancename

s = Template(xmlstring)

#iterate over instances/ match the one we need

for i in doc.get("application").get("instance", None):

#when found

# s/r properties in xml and then convert it back to dict

try:

if i.get("@name", None) == instancename:

try:

instance_property = dict(i.get("property"))

final_string = s.safe_substitute(instance_property)

final_dict = xmltodict.parse(final_string)

except TypeError:

final_dict = doc

# Handle strings in case of dict, strings do not have get method.

except AttributeError:

final_dict = doc



and when i am trying to get the version no. using a function for getting
the package version



def _getPackgeVersion(xmlfile, p):

package = str(p)

if isinstance(fpmdict["application"]["package"], list):

for i in fpmdict["application"]["package"]:

if i["@name"] == p:

_pkgVersion = i["version"]

else:

_pkgversion = fpmdict["application"]["package"]["version"]

return _pkgVersion



pkgVersion = _getPackgeVersion(final_doc, testpackage)

print type(pkgVersion)



I am getting the below error


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

Re: __next__ and StopIteration

[Chris Angelico]

On Tue, Feb 10, 2015 at 5:16 PM, Charles Hixson
 wrote:
> Yes, rows and cols are lists, but I'm going to need to iterate through them
> more than once.  I'd rather do without a included class, but if a properly
> formed iterator can only be cycled through once, and if I understand
> properly that means I can't use the "class instance is it's own iterator"
> form.

When you write __iter__ as a generator function, what you actually
have is a factory for iterator objects. (Generators are iterators.)
When something calls __iter__ on your Grid, it gets back a brand new
iterator which is independent of every other iterator from that or any
other Grid, so you can iterate over the same Grid more than once.
You're not writing __next__ here, so you're not using the class
instance as its own iterator, which means that that consideration
doesn't apply.

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

Re: __next__ and StopIteration

[Charles Hixson]

On 02/09/2015 08:46 PM, Chris Angelico wrote:

On Tue, Feb 10, 2015 at 3:33 PM, Charles Hixson
 wrote:

The proper version of the "hard way" is:

1) The __iter__ method of the iterable constructs a new iterator
instance and returns it.

2) The __iter__ method of the *iterator* simply returns itself.

3) The __next__ method of the iterator tracks the current value and
returns the next value. Note that the iterator should never store the
iterable's data internally, unless the iterable is immutable and the
calculation is trivial (e.g. a range object). Instead, it should
determine the next value by referring to its source iterable.

So if I'm understanding this correctly, I should implement as an internal
class within Grid something like:
 class GridIter(Iterator):

Apart from the fact that you shouldn't have to explicitly subclass
Iterator, yes. But this is the hard way to do things. The easy way is
to simply define an __iter__ method on your Grid which returns an
iterator - and one excellent form of iterator, for custom classes like
this, is a generator object. Your original code can slot happily in,
with one tiny change:

class Grid:
 blah blah

 def __iter__(self):
 for row in range(self._rows):
 for col in range(self._cols):
 if self._grid[row][col]:
 yield self._grid[row][col]

The only change is to remove the explicit StopIteration at the end;
once your generator function terminates, the generator object will
raise StopIteration forever afterward, without any help from you.
(Also, post-PEP479, the explicit raise will actually cause
RuntimeError, so it's not just superfluous, but actually a problem.)

But I'm guessing that your grid and rows are actually iterable
themselves. If they are, you can cut the code down to this:

 def __iter__(self):
 for row in self._grid:
 for cell in row:
 if cell: yield cell

or a generator expression:

 def __iter__(self):
 return (cell for row in self._grid for cell in row if cell)

or itertools.chain and filter, if you so desired. As long as you
return an iterator, you're fine. This is far and away the easiest way
to make a class iterable.

ChrisA
Yes, rows and cols are lists, but I'm going to need to iterate through 
them more than once.  I'd rather do without a included class, but if a 
properly formed iterator can only be cycled through once, and if I 
understand properly that means I can't use the "class instance is it's 
own iterator" form.

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

Re: __next__ and StopIteration

[Steven D'Aprano]

Chris Kaynor wrote:

> On Mon, Feb 9, 2015 at 4:42 PM, Steven D'Aprano
>  wrote:
>> so that's an excellent sign that doing so is best practice, but it should
>> not be seen as *required*. After all, perhaps you have good reason for
>> wanting your iterable class to only be iterated over once.
> 
> In fact, there is one in the stdlib, the "file" object, which has a
> __iter__ which returns self. The code below shows this,
[...]
> The "file" object is also an example of this. It is technically a
> broken iterator according to the docs:


Awesome example!

-- 
Steve

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

Re: TypeError: list indices must be integers, not tuple

[Terry Reedy]

On 2/9/2015 6:52 PM, james8boo...@hotmail.com wrote:

import random
RandomNum = random.randint(0,7)
restraunt = raw_input("What's your favourite takeaway?Pizza, Chinease or 
Indian?")
if restraunt == ("Pizza"):
 fav = ("1")


As a style note, putting parentheses around strings is worse than useless.


elif restraunt == ("Chinease"):
 fav = ("2")

elif restraunt == ("Indian"):
 fav = ("3")

else:
 print("Try using a capital letter, eg; 'Chinease'")

Menu = [["Barbeque pizza","Peparoni","Hawain"],["Curry","Noodles","Rice"],["Tika 
Masala","Special Rice","Onion Bargees"]]

print Menu[fav,RandomNum]
^
TypeError: list indices must be integers, not tuple

How do I set a variable to a random number then use it as a list indece, (I'm 
only a student in his first 6 months of using python)




--
Terry Jan Reedy

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

Re: TypeError: list indices must be integers, not tuple

[Dave Angel]

On 02/09/2015 10:05 PM, Dave Angel wrote:

On 02/09/2015 07:02 PM, Ethan Furman wrote:

On 02/09/2015 03:52 PM, james8boo...@hotmail.com wrote:

import random
RandomNum = random.randint(0,7)
restraunt = raw_input("What's your favourite takeaway?Pizza, Chinease
or Indian?")
if restraunt == ("Pizza"):
 fav = ("1")

elif restraunt == ("Chinease"):
 fav = ("2")

elif restraunt == ("Indian"):
 fav = ("3")

else:
 print("Try using a capital letter, eg; 'Chinease'")



So just what is RandomNum supposed to represent?  You've selected it
from an interval of 0 to 7, but you don't have 8 of anything.  The most
logical possibility I can figure is you want to use it instead of
whatever the user has typed into your raw input.  Like in the else
clause.  If that's the case, you'd want to add a
  fav = RandomNum
line in the else clause.

Of course, as Ethan has pointed out, all the other assignments to fav
want to be integer, not string.  You can't use a string to index a lis.


Menu = [["Barbeque
pizza","Peparoni","Hawain"],["Curry","Noodles","Rice"],["Tika
Masala","Special Rice","Onion Bargees"]]

print Menu[fav,RandomNum]


Now that you've got a single value for fav, just say
 print Menu[fav]
to print the submenu.

Now if Ethan has guessed right, that you wanted the random value to
choose from the submenu, then you would/should have created it after you
have the submenu, so you know how many possibilities there are.


Something like (untested):
RandomNum = random.randint(0, len(submenu)-1)





Perhaps it's worth suggesting that you use random.choice() instead, and 
use it directly on the sublist.  If you also make your data structure a 
dict of lists, then the whole thing becomes very simple.


(untested)

Menu = {
 "Pizza" : ["Barbeque pizza","Peparoni","Hawain"],
 "Chinease" : ["Curry","Noodles","Rice"],["Tika Masala",
 "Indian" : "Special Rice","Onion Bargees"]
   }

restraunt = raw_input("What's your favourite takeaway?Pizza, Chinease or 
Indian?")


submenu = menu[restraunt]
#you might want some error handling, in case they get it wrong
fooditem = random.choice(submenu)

print fooditem


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

Re: __next__ and StopIteration

[Chris Angelico]

On Tue, Feb 10, 2015 at 3:33 PM, Charles Hixson
 wrote:
>> The proper version of the "hard way" is:
>>
>> 1) The __iter__ method of the iterable constructs a new iterator
>> instance and returns it.
>>
>> 2) The __iter__ method of the *iterator* simply returns itself.
>>
>> 3) The __next__ method of the iterator tracks the current value and
>> returns the next value. Note that the iterator should never store the
>> iterable's data internally, unless the iterable is immutable and the
>> calculation is trivial (e.g. a range object). Instead, it should
>> determine the next value by referring to its source iterable.
>
> So if I'm understanding this correctly, I should implement as an internal
> class within Grid something like:
> class GridIter(Iterator):

Apart from the fact that you shouldn't have to explicitly subclass
Iterator, yes. But this is the hard way to do things. The easy way is
to simply define an __iter__ method on your Grid which returns an
iterator - and one excellent form of iterator, for custom classes like
this, is a generator object. Your original code can slot happily in,
with one tiny change:

class Grid:
blah blah

def __iter__(self):
for row in range(self._rows):
for col in range(self._cols):
if self._grid[row][col]:
yield self._grid[row][col]

The only change is to remove the explicit StopIteration at the end;
once your generator function terminates, the generator object will
raise StopIteration forever afterward, without any help from you.
(Also, post-PEP479, the explicit raise will actually cause
RuntimeError, so it's not just superfluous, but actually a problem.)

But I'm guessing that your grid and rows are actually iterable
themselves. If they are, you can cut the code down to this:

def __iter__(self):
for row in self._grid:
for cell in row:
if cell: yield cell

or a generator expression:

def __iter__(self):
return (cell for row in self._grid for cell in row if cell)

or itertools.chain and filter, if you so desired. As long as you
return an iterator, you're fine. This is far and away the easiest way
to make a class iterable.

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

Re: __next__ and StopIteration

[Charles Hixson]

On 02/09/2015 03:56 PM, Ian Kelly wrote:

On Mon, Feb 9, 2015 at 4:30 PM, Steven D'Aprano
 wrote:

The way you write iterators is like this:


Method 1 (the hard way):

- Give your class an __iter__ method which simply returns self:

 def __iter__(self):
 return self

- Give your class a __next__ method (`next` in Python 2) which *returns* a
value. You will need to track which value to return yourself. It must raise
StopIteration when there are no more values to return. Don't use yield.

 def __next__(self):
 value = self.value
 if value is None:
 raise StopIteration
 self.value = self.calculate_the_next_value()
 return value

Your class is itself an iterator.

This is an anti-pattern, so don't even suggest it. Iterables should
never be their own iterators. Otherwise, your iterable can only be
iterated over once!

The proper version of the "hard way" is:

1) The __iter__ method of the iterable constructs a new iterator
instance and returns it.

2) The __iter__ method of the *iterator* simply returns itself.

3) The __next__ method of the iterator tracks the current value and
returns the next value. Note that the iterator should never store the
iterable's data internally, unless the iterable is immutable and the
calculation is trivial (e.g. a range object). Instead, it should
determine the next value by referring to its source iterable.
So if I'm understanding this correctly, I should implement as an 
internal class within Grid something like:

class GridIter(Iterator):
""" A class to iterate over the cells of a Grid instance
Vars:
  row  ::  The row currently being iterated over.
  col  ::  Yhe column currently being iterated over.
  grid ::  The grid instance being iterated over.
"""

def __init__ (self, grid):
"""
Params:
  grid  ::  The instance of the grid to iterate over.
"""
self.row=-1
self.col=-1
self.grid=grid
#end__init__

def __iter__ (self):
returnself

def __next__ (self):
if self.row == -1 and self.col == -1:
self.row=0
self.col=0
elif self.col >= grid.cols():
self.row=self.row + 1
self.col=0
if self.row > grid.rows():
raiseStopIteration
if not[row, col] in self.grid:
returnself.__next__()
returngrid(row, col)

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

Re: Weird behavior on __dict__ attr

[Dave Angel]

On 02/09/2015 09:52 PM, Shiyao Ma wrote:

Hi.

My context is a little hard to reproduce.


WHY don't you try?  Telling us about a class without showing how it's 
defined leaves us all guessing.


Start by telling us Python version.  And if it's 2.x, tell us whether 
this class is an old style or new style class.




NS3 is a network simulation tool written in C++. I am using its Python binding.

So the class I am dealing with is from a .so file.

Say, I do the following:

%

import ns.network.Node as Node

# Node is a class
# it has a __dict__ attr

# Now I instantiate an instance of Node
n = Node()

# I checked, there is no __dict__ on 'n'
# but the following succeeds.

n.foobar = 3



My understanding is the foobar is stored in n.__dict__, but seemingly n has no 
__dict__.

So where does the foobar go?



Lots of possibilities.  Simplest is slots.  if you define __slots__, 
then there's no dictionary in each instance.


https://docs.python.org/3.4/reference/datamodel.html#slots

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

Re: TypeError: list indices must be integers, not tuple

[Dave Angel]

On 02/09/2015 07:02 PM, Ethan Furman wrote:

On 02/09/2015 03:52 PM, james8boo...@hotmail.com wrote:

import random
RandomNum = random.randint(0,7)
restraunt = raw_input("What's your favourite takeaway?Pizza, Chinease or 
Indian?")
if restraunt == ("Pizza"):
 fav = ("1")

elif restraunt == ("Chinease"):
 fav = ("2")

elif restraunt == ("Indian"):
 fav = ("3")

else:
 print("Try using a capital letter, eg; 'Chinease'")



So just what is RandomNum supposed to represent?  You've selected it 
from an interval of 0 to 7, but you don't have 8 of anything.  The most 
logical possibility I can figure is you want to use it instead of 
whatever the user has typed into your raw input.  Like in the else 
clause.  If that's the case, you'd want to add a

 fav = RandomNum
line in the else clause.

Of course, as Ethan has pointed out, all the other assignments to fav 
want to be integer, not string.  You can't use a string to index a lis.



Menu = [["Barbeque pizza","Peparoni","Hawain"],["Curry","Noodles","Rice"],["Tika 
Masala","Special Rice","Onion Bargees"]]

print Menu[fav,RandomNum]


Now that you've got a single value for fav, just say
print Menu[fav]
to print the submenu.

Now if Ethan has guessed right, that you wanted the random value to 
choose from the submenu, then you would/should have created it after you 
have the submenu, so you know how many possibilities there are.



Something like (untested):
RandomNum = random.randint(0, len(submenu)-1)



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

Weird behavior on __dict__ attr

[Shiyao Ma]

Hi.

My context is a little hard to reproduce.

NS3 is a network simulation tool written in C++. I am using its Python binding.

So the class I am dealing with is from a .so file.

Say, I do the following:

%

import ns.network.Node as Node

# Node is a class
# it has a __dict__ attr

# Now I instantiate an instance of Node
n = Node()

# I checked, there is no __dict__ on 'n'
# but the following succeeds.

n.foobar = 3



My understanding is the foobar is stored in n.__dict__, but seemingly n has no 
__dict__.

So where does the foobar go?


TIA.



-- 
Shiyao Ma
http://introo.me
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: __next__ and StopIteration

[Chris Angelico]

On Tue, Feb 10, 2015 at 12:11 PM, Steven D'Aprano
 wrote:
>> Yes, it is allowed. But when you write code that's documented as being
>> "broken", you should expect annoying, subtle errors, maybe a long way
>> down the track.
>
> Well, that depends, don't it?
>
> Am I really going to care if the iterator used to generate those random
> numbers is technically "broken"? Probably not. And if I do, some time in
> the distant future, oh well, I'll "fix" it then.

If you inhale asbestos, you should expect annoying, maybe subtle,
errors, maybe a long way down the track. Good news is, the lab boys
say the symptoms of asbestos poisoning show a median latency of 44.6
years, so if you're thirty or older, you're laughing. Worst case
scenario, you miss out on a few rounds of canasta. Do you care that
your lungs are technically "broken"? Probably not. It's something to
be aware of when you consider working in certain environments, but "be
aware of" doesn't mean "absolutely always avoid".

Okay, maybe it does with asbestos... but not with broken iterators. :)

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

Re: __next__ and StopIteration

[Ned Batchelder]

On 2/9/15 2:24 PM, Ned Batchelder wrote:

On 2/9/15 2:14 PM, Charles Hixson wrote:

I'm trying to write a correct iteration over a doubly indexed container,
and what I've got so far is:def __next__ (self):
 for rowinrange(self._rows):
 for col in range(self._cols):
 if self._grid[row][col]:
 yieldself._grid[row][col]
 #endif
 #endfor col
 #endfor row
 raiseStopIteration

What bothers me is that it doesn't look like it would continue to raise
StopIteration if it were called again, which is what
https://docs.python.org/3/library/stdtypes.html#iterator.__next__ says
is correct.  How should this be fixed?


You are using yield, which means __next__ is a generator.  As such, you
don't have to explicitly raise StopIteration at all.  Just remove that
statement, and you should be fine.

Also, look into how you are posting, the code is nearly mangled. :(



Oops, __next__ isn't right here, it should be __iter__:

def __iter__(self):
for row in range(self._rows):
for col in range(self._cols):
if self._grid[row][col]:
yield self._grid[row][col]

--
Ned Batchelder, http://nedbatchelder.com

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

Re: __next__ and StopIteration

[Steven D'Aprano]

Chris Angelico wrote:

> On Tue, Feb 10, 2015 at 11:42 AM, Steven D'Aprano
>  wrote:
>> Also, *technically* iterators may be re-iterable. The docs say that
>> iterators which fail to raise StopIteration forever once they are
>> exhausted are "broken", but the docs do not forbid broken iterators.
>> Consenting adults and all that. You might want an iterator with a reset()
>> method. Even an outright broken iterator!
>>
>> def __next__(self):
>> if random.random() < 0.1: raise StopIteration
>> return random.random()
>>
>> Why you would want one, I don't know, but if you have a hankering for
>> such a beast, Python lets you do it.
> 
> Yes, it is allowed. But when you write code that's documented as being
> "broken", you should expect annoying, subtle errors, maybe a long way
> down the track.

Well, that depends, don't it?

If you're writing library code, you need to be much more careful and
thoughtful about both your API and implementation.

But if you're writing something quick and dirty for a one-off script, even a
script that is going to be used in perpetuity, you can afford a lot more
sloppiness. Better something sloppy that works today than something perfect
next year. Say my script just outputs a bunch of random numbers, one per
line, and I pipe the output to a file in the shell:

mkrnd.py > the_numbers.txt

Am I really going to care if the iterator used to generate those random
numbers is technically "broken"? Probably not. And if I do, some time in
the distant future, oh well, I'll "fix" it then.



-- 
Steven

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

Re: __next__ and StopIteration

[Chris Kaynor]

On Mon, Feb 9, 2015 at 4:42 PM, Steven D'Aprano
 wrote:
> so that's an excellent sign that doing so is best practice, but it should
> not be seen as *required*. After all, perhaps you have good reason for
> wanting your iterable class to only be iterated over once.

In fact, there is one in the stdlib, the "file" object, which has a
__iter__ which returns self. The code below shows this,

There are a number of good reasons: perhaps there is no good way to
reset the iterator or there is outside state that has to be managed.
I'm also sure there are other reasons I cannot think of right now.

>
> Also, *technically* iterators may be re-iterable. The docs say that
> iterators which fail to raise StopIteration forever once they are exhausted
> are "broken", but the docs do not forbid broken iterators. Consenting
> adults and all that. You might want an iterator with a reset() method. Even
> an outright broken iterator!
>
> def __next__(self):
> if random.random() < 0.1: raise StopIteration
> return random.random()
>
> Why you would want one, I don't know, but if you have a hankering for such a
> beast, Python lets you do it.

The "file" object is also an example of this. It is technically a
broken iterator according to the docs:

Python 3.4.2 (v3.4.2:ab2c023a9432, Oct  6 2014, 22:15:05) [MSC v.1600
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open("d:/test.txt")
>>> iter(f) is f
True
>>> for l in f:
... print(l)
...
line 1

line 2

line 3

>>> for l in f:
... print(l)
...
>>> f.seek(0)
0
>>> for l in f:
... print(l)
...
line 1

line 2

line 3

>>> next(f)
Traceback (most recent call last):
  File "", line 1, in 
StopIteration
>>> f.seek(0)
0
>>> next(f) # This should throw StopIteration as it has previously thrown 
>>> StopIteration.
'line 1\n'
>>>



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

Re: __next__ and StopIteration

[Chris Angelico]

On Tue, Feb 10, 2015 at 11:42 AM, Steven D'Aprano
 wrote:
> Also, *technically* iterators may be re-iterable. The docs say that
> iterators which fail to raise StopIteration forever once they are exhausted
> are "broken", but the docs do not forbid broken iterators. Consenting
> adults and all that. You might want an iterator with a reset() method. Even
> an outright broken iterator!
>
> def __next__(self):
> if random.random() < 0.1: raise StopIteration
> return random.random()
>
> Why you would want one, I don't know, but if you have a hankering for such a
> beast, Python lets you do it.

Yes, it is allowed. But when you write code that's documented as being
"broken", you should expect annoying, subtle errors, maybe a long way
down the track. You know all those niggling problems you get when you
find some NaNs in a series of numbers, and suddenly things don't sort
stably and such? You'll hanker for those well-defined days. :)

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

Re: __next__ and StopIteration

[Steven D'Aprano]

Ian Kelly wrote:

> On Mon, Feb 9, 2015 at 4:30 PM, Steven D'Aprano
>  wrote:
[...]
>> Your class is itself an iterator.
> 
> This is an anti-pattern, so don't even suggest it. Iterables should
> never be their own iterators. Otherwise, your iterable can only be
> iterated over once!

Hmmm, good point.

However, I will point out a couple of factors:

Ultimately, that's the correct behaviour for *iterator* classes. With the
rich set of tools available to build iterators from built-in parts, it is
rare that you need to write your own class with a __next__ method, but if
you do, that's the way you want it to behave.

Whether that *iterator* class should be the same class as the *iterable*
class is another story. In the built-ins, they mostly (always?) come in
pairs:

tuple <-> tuple_iterator
list <-> list_iterator
dict <-> dict_keyiterator
set <-> set_iterator
range <-> range_iterator

so that's an excellent sign that doing so is best practice, but it should
not be seen as *required*. After all, perhaps you have good reason for
wanting your iterable class to only be iterated over once.

Also, *technically* iterators may be re-iterable. The docs say that
iterators which fail to raise StopIteration forever once they are exhausted
are "broken", but the docs do not forbid broken iterators. Consenting
adults and all that. You might want an iterator with a reset() method. Even
an outright broken iterator!

def __next__(self):
if random.random() < 0.1: raise StopIteration
return random.random()

Why you would want one, I don't know, but if you have a hankering for such a
beast, Python lets you do it.


> The proper version of the "hard way" is:
> 
> 1) The __iter__ method of the iterable constructs a new iterator
> instance and returns it.
> 
> 2) The __iter__ method of the *iterator* simply returns itself.
> 
> 3) The __next__ method of the iterator tracks the current value and
> returns the next value. Note that the iterator should never store the
> iterable's data internally, unless the iterable is immutable and the
> calculation is trivial (e.g. a range object). Instead, it should
> determine the next value by referring to its source iterable.


-- 
Steven

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

Re: Python 3.x stuffing utf-8 into SQLite db

[Skip Montanaro]

On Mon, Feb 9, 2015 at 2:38 PM, Skip Montanaro 
wrote:

> On Mon, Feb 9, 2015 at 2:05 PM, Zachary Ware
>  wrote:
> > If all else fails, you can try ftfy to fix things:
> > http://ftfy.readthedocs.org/en/latest/
>
> Thanks for the pointer. I would prefer to not hand-mangle this stuff
> in case I get another database dump from my USMS friends. Something
> like ftfy should help things "just work".
>

And indeed it did. Thanks Zachary.

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

Re: TypeError: list indices must be integers, not tuple

[Ethan Furman]

On 02/09/2015 03:52 PM, james8boo...@hotmail.com wrote:
> import random
> RandomNum = random.randint(0,7)
> restraunt = raw_input("What's your favourite takeaway?Pizza, Chinease or 
> Indian?")
> if restraunt == ("Pizza"):
> fav = ("1")
> 
> elif restraunt == ("Chinease"):
> fav = ("2")  
> 
> elif restraunt == ("Indian"):
> fav = ("3")
> 
> else:
> print("Try using a capital letter, eg; 'Chinease'")
> 
> Menu = [["Barbeque 
> pizza","Peparoni","Hawain"],["Curry","Noodles","Rice"],["Tika 
> Masala","Special Rice","Onion Bargees"]]
> 
> print Menu[fav,RandomNum]
>^
> TypeError: list indices must be integers, not tuple
> 
> How do I set a variable to a random number then use it as a list indece, (I'm 
> only a student in his first 6 months of using python) 

When you say

 Menu[fav,RandomNum]

the `fav,RandomNum` portion is a tuple.

`fav` should be 1 or 2 or 3, not "1" nor "2" nor "3".

`RandomNum` should be be `random.randint(0,2)`

Finally:

submenu = Menu[fav]

random_food = submenu[RandomNum]

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Please help.

[Steven D'Aprano]

Hello Chimex, and welcome.

First, before I answer your question, I have a favour to ask. Please adjust
your email program to send Plain Text as well as (or even instead of)
so-called "Rich Text". When you send Rich Text, many people here will see
your email like this:

chime...@gmail.com wrote:

> 
> body {  font-family: "Calibri","Slate Pro","sans-serif"; color:#262626
> }   style="">‎Hello. Am trying to change the key words to my tribal
> language. Eg change English language: print() to igbo language: de(). I
> have been stuck for months I need a mentor or someone that can guide me
> and answer some of my questions when I get stuck.
> Thanks..I will really appreciate it if someone attends
> to me.

I hope you understand why most people won't bother to try to read or respond
to such a mess. So-called "Rich Text" (actually HTML) bloats your email,
making it bigger and slower than it needs to be, and it can be a security
threat to the receiver (unscrupulous people can insert hostile code in the
HTML, or web bugs, or other nasties). Or worse, it means that we're stuck
with reading people's messages in some unspeakably horrible combination of
ugly fonts, clashing colours and dancing fairies dancing across the page.
So please understand that especially on a technical forum like this,
probably 90% of of people will respond poorly to anything written in Rich
Text alone.

Moving on to your actual question:

Am trying to change the key words to my tribal
language. Eg change English language: print() to 
igbo language: de().

I know of two projects that do the same thing, ChinesePython and Teuton.


http://www.chinesepython.org/

http://reganmian.net/blog/2008/11/21/chinese-python-translating-a-programming-language/

http://www.fiber-space.de/EasyExtend/doc/teuton/teuton.htm

The Teuton page links to a post on Artima by Andy Dent which discusses this
further.

Basically, the idea is that you start with the source code to Python,
written in C, change the keywords, and recompile. If nothing breaks, you
should then be able to program using non-English keywords.

As an alternative, you might consider using a pre-processor which translates
your dialect of Python+Igbo to standard Python before running the code.
Google for LikePython and LOLPython for some ideas.



-- 
Steven

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

Re: __next__ and StopIteration

[Ian Kelly]

On Mon, Feb 9, 2015 at 4:30 PM, Steven D'Aprano
 wrote:
> The way you write iterators is like this:
>
>
> Method 1 (the hard way):
>
> - Give your class an __iter__ method which simply returns self:
>
> def __iter__(self):
> return self
>
> - Give your class a __next__ method (`next` in Python 2) which *returns* a
> value. You will need to track which value to return yourself. It must raise
> StopIteration when there are no more values to return. Don't use yield.
>
> def __next__(self):
> value = self.value
> if value is None:
> raise StopIteration
> self.value = self.calculate_the_next_value()
> return value
>
> Your class is itself an iterator.

This is an anti-pattern, so don't even suggest it. Iterables should
never be their own iterators. Otherwise, your iterable can only be
iterated over once!

The proper version of the "hard way" is:

1) The __iter__ method of the iterable constructs a new iterator
instance and returns it.

2) The __iter__ method of the *iterator* simply returns itself.

3) The __next__ method of the iterator tracks the current value and
returns the next value. Note that the iterator should never store the
iterable's data internally, unless the iterable is immutable and the
calculation is trivial (e.g. a range object). Instead, it should
determine the next value by referring to its source iterable.
-- 
https://mail.python.org/mailman/listinfo/python-list

TypeError: list indices must be integers, not tuple

[james8booker]

import random
RandomNum = random.randint(0,7)
restraunt = raw_input("What's your favourite takeaway?Pizza, Chinease or 
Indian?")
if restraunt == ("Pizza"):
fav = ("1")

elif restraunt == ("Chinease"):
fav = ("2")  

elif restraunt == ("Indian"):
fav = ("3")

else:
print("Try using a capital letter, eg; 'Chinease'")

Menu = [["Barbeque 
pizza","Peparoni","Hawain"],["Curry","Noodles","Rice"],["Tika Masala","Special 
Rice","Onion Bargees"]]

print Menu[fav,RandomNum]
   ^
TypeError: list indices must be integers, not tuple

How do I set a variable to a random number then use it as a list indece, (I'm 
only a student in his first 6 months of using python) 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: __next__ and StopIteration

[Steven D'Aprano]

Charles Hixson wrote:

> I'm trying to write a correct iteration over a doubly indexed container,
> and what I've got so far is:def __next__ (self):
>  for rowinrange(self._rows):
>  for col in range(self._cols):
>  if self._grid[row][col]:
>  yieldself._grid[row][col]
>  #endif
>  #endfor col
>  #endfor row
>  raiseStopIteration

That's wrong, you don't use yield in __next__ as that will turn it into a
generator function. Here is a simplified example demonstrating the problem:


py> class X(object):
... def __next__(self):
... yield 1
... yield 2
...
py> x = X()
py> next(x)

py> next(x)

py> next(x)

py> next(x)



The way you write iterators is like this:


Method 1 (the hard way):

- Give your class an __iter__ method which simply returns self:

def __iter__(self):
return self

- Give your class a __next__ method (`next` in Python 2) which *returns* a
value. You will need to track which value to return yourself. It must raise
StopIteration when there are no more values to return. Don't use yield.

def __next__(self):
value = self.value
if value is None:
raise StopIteration
self.value = self.calculate_the_next_value()
return value

Your class is itself an iterator.

Method 2 (the easy way):

- Don't write a __next__ method at all.

- Give your class an __iter__ method which returns an iterator. E.g.:

def __iter__(self):
return iter(self.values)

In this case, your class is not itself an iterator, but it is iterable:
calling iter(myinstance) will return an iterator, which is enough.

If you don't have a convenient collection of values to return, you can
conveniently use a generator, yielding values you want and just falling off
the end (or returning) when you are done. E.g.:

def __iter__(self):
while self.value is not None:
yield self.value
self.calculate_the_next_value()

In your case, it looks to me that what you need is something like:


def __iter__(self):
for row in range(self._rows):
for col in range(self._cols):
if self._grid[row][col]:
yield self._grid[row][col]

which is probably better written as:

# untested -- I may have the row/col order backwards
def __iter__(self):
for column in self._grid:
for item in column:
if value:
yield value


As a general rule, Python is not Fortran. If you find yourself wanting to
write code that iterates over an index, then indexes into a list or array,
99.9% of the time you are better off just iterating over the list or array
directly:

# not this!
for i in range(len(mylist)):
value = mylist[i]
print(value)

# instead use this
for value in mylist:
print(value)


If you need both the index and the list item, use enumerate:

for i, value in enumerate(mylist):
print(i, value)



-- 
Steven

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

Re: Python 3 and the requests library

[Ian Kelly]

On Mon, Feb 9, 2015 at 2:37 PM, Brian  wrote:
> Thank you, Ian and Zack! That was exactly the issue. Apparently, having a 
> token.py script (one of my first Python 2 scripts to get an authorization 
> token from a billing server) is OK for Python 2 but breaks Python 3.

Local modules that have the same absolute module path as standard
library modules will cause problems in either version of Python. I
think it's unfortunate that Python files that happen to live in the
same directory as the main script automatically get treated as
top-level modules that shadow the standard library. You're not the
first person to be confused by this.

It appears that the reason this works for you in Python 2 and not in
Python 3 is because the linecache module doesn't import tokenize in
Python 2, whereas it does in Python 3. If you had tried to import
tokenize directly in Python 2 then I expect you'd have the same
problem.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Monte Carlo probability calculation in Python

[Paul Moore]

On Friday, 6 February 2015 23:49:51 UTC, Steven D'Aprano  wrote:
> > Just a quick status update, in case you're interested. With relatively
> > little work (considering I started not knowing much about numpy) I managed
> > to put together solutions for a couple of my friend's problems which ran
> > in basically the same time as his custom C code. Very impressive!
> 
> Very nice! Care to share the code?

Will do. I'll have to do some tidying up (at the moment, it's in an IPython 
notebook on my PC, full of chunks of code trying various approaches) but I'll 
post it in a few days.

The C++ code isn't postable, unfortunately, as it's not open source. Also, it's 
not *quite* custom C++, but rather an expression you feed into his program that 
does this type of calculation. The program's built specifically for doing this 
type of problem, and runs an expression tree in a tight C++ loop (there's a 
small virtual function call overhead, but that's about it). More accurately, I 
guess, it's a custom C++ application for solving this class of problem. But 
regardless, I'd expected Python to only manage to be "good enough", not to 
equal the C++ application, so I'm still impressed!

But it's a nice problem as an introduction to numpy - hard enough to be worth 
the effort, and it *needs* the performance numpy gives. But simple enough that 
solving it is achievable.

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

Re: Python 3 and the requests library

[Brian]

Thank you, Ian and Zack! That was exactly the issue. Apparently, having a 
token.py script (one of my first Python 2 scripts to get an authorization token 
from a billing server) is OK for Python 2 but breaks Python 3.

*face palm*

Thank you again so very much!

Brian

On Monday, February 9, 2015 at 3:59:11 PM UTC-5, Ian wrote:
> On Mon, Feb 9, 2015 at 1:37 PM, Brian wrote:
> > Zach,
> >
> > Here is what I get on the Mac:
> >
> > $ python3 -c "import token;print(token.__file__)"
> > /Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/token.py
> 
> Are you running this from the same directory where you have your test
> scripts (in case there is also a token module hanging around in that
> directory)?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What killed Smalltalk could kill Python

[Ethan Furman]

On 01/21/2015 03:37 PM, Tim Daneliuk wrote:
> 
> I wrote some rambling disquisition on these matters some years ago ...
> 
>   http://www.tundraware.com/TechnicalNotes/Python-Is-Middleware
> 
>   http://www.tundraware.com/TechnicalNotes/How-To-Pick-A-Programming-Language

Very enjoyable, thank you!

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 and the requests library

[Zachary Ware]

On Mon, Feb 9, 2015 at 2:37 PM, Brian  wrote:
> Zach,
>
> Here is what I get on the Mac:
>
> $ python3 -c "import token;print(token.__file__)"
> /Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/token.py

That looks correct.

> Just for grins, I also ran it against the built-in Python 2.7.5 version:
>
> $ python -c "import token;print(token.__file__)"
> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/token.pyc
>
> The only difference seems to be that the 2.7.5 version has precompiled it.

The 3.4 version is also precompiled, but __file__ gives the filename
of the actual module (not the .pyc implementation detail).  You can
find precompiled token.py for 3.4 at
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/__pycache__/token.cpython-34.pyc

> Then I followed your example but ran it against the logging module instead, 
> as that
> seems to be where the problem lies.

Not so, the traceback you posted shows pretty clearly that the problem
is in the tokenize module, where the token module it has imported does
not have an __all__ attribute.

> Again, for both version (broken 3 and working 2) as a comparison:
>
> $ python3 -c "import logging;print(logging.__file__)"
> /Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/logging/__init__.py

This should have failed with the same traceback as your test2.py.

> $ python -c "import logging;print(logging.__file__)"
> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/logging/__init__.pyc
>
> But nothing is pointing to anything except what appears to be the formally 
> installed
> versions of these library modules.

Try your test again.  If it fails again, run my test again at the same prompt.

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

Re: Python 3 and the requests library

[Ian Kelly]

On Mon, Feb 9, 2015 at 1:37 PM, Brian  wrote:
> Zach,
>
> Here is what I get on the Mac:
>
> $ python3 -c "import token;print(token.__file__)"
> /Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/token.py

Are you running this from the same directory where you have your test
scripts (in case there is also a token module hanging around in that
directory)?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: locale bug in Python 2.7, 3.3, 3.4 (Win7 64)?

[Albert-Jan Roskam]

- Original Message -

> From: Mark Lawrence 
> To: python-list@python.org
> Cc: 
> Sent: Monday, February 9, 2015 5:02 PM
> Subject: Re: locale bug in Python 2.7, 3.3, 3.4 (Win7 64)?
> 
> On 09/02/2015 15:43, Albert-Jan Roskam wrote:
>>  Hi,
>> 
>>  In the locale module we have:
>>  * setlocale, the setter that also returns something
>>  * getlocale, the getter that returns the OS-specific locale tuple 
> (supposedly!)
>> 
>>  * getdefaultlocale, the getter that always returns a unix locale tuple
>> 
>>  Why are the getlocale() results below sometimes windows-like, sometimes 
> unix-like?
>>  It seems that I need to use setlocale(), with only the 'category' 
> parameter, right?
>> 
>> 
>>  ActivePython 3.3.2.0 (ActiveState Software Inc.) based on
>>  Python 3.3.2 (default, Sep 16 2013, 23:11:39) [MSC v.1600 64 bit (AMD64)] 
> on win32
>>  Type "help", "copyright", "credits" or 
> "license" for more information.
>  import locale
>  locale.getlocale()
>>  (None, None)   # because setocale has not been called yet
>> 
>> 
>>  # works as expected
>> 
>  locale.setlocale(locale.LC_ALL, "")
>>  'Dutch_Netherlands.1252'
>  locale.getlocale()
>>  ('Dutch_Netherlands', '1252')
>> 
>>  # bug!>>> locale.setlocale(locale.LC_ALL, "german")
>>  'German_Germany.1252'
>  locale.getlocale()
>>  ('de_DE', 'cp1252') # incorect, unix-like!
>> 
>> 
>  locale.setlocale(locale.LC_ALL, 
> "German_Germany.1252")
>>  'German_Germany.1252'
>  locale.getlocale()
>>  ('de_DE', 'cp1252') # incorect, unix-like!
>> 
>> 
>>  # bug!
>> 
>  locale.setlocale(locale.LC_ALL, "spanish")
>>  'Spanish_Spain.1252'
>  locale.getlocale()
>>  ('es_ES', 'cp1252')   # incorect, unix-like!
>> 
>> 
>>  # works as expected
>  locale.setlocale(locale.LC_ALL, "italian")
>>  'Italian_Italy.1252'
>  locale.getlocale()
>>  ('Italian_Italy', '1252')# correct!
>> 
>> 
>>  # ... maybe more?
>> 
>> 
>>  Regards,
>> 
>>  Albert-Jan
>> 
> 
> There have been loads of bug reports on the issue tracker about locales. 
>   I suggest that you take a look to see if there is an open issue about 
> this problem.


Hi Mark -Thanks! I checked the bug tracker. Lots of locale-related bugs indeed. 
I couldn't find this one though. Strange because what I am doing does not seem 
exotic at all. French, German, Portuguese and Spanish getlocale results are 
incorrect IMHO. Below is little check + output here in case it might be useful 
for others. This is with Python 3.4, 3.3 and 2.7 on Windows 7 64.

from __future__ import print_function
import locale
import collections
import pprint


#https://msdn.microsoft.com/en-us/library/39cwe7zf%28v=vs.80%29.aspx
languages = ("chinese czech danish dutch english finnish french german greek "
 "hungarian icelandic italian japanese korean norwegian polish "
 "portuguese russian slovak spanish swedish turkish")
d = collections.defaultdict(list)
t = collections.namedtuple("Locale", "lang setlocale getlocale")
for language in languages.split():
sloc = locale.setlocale(locale.LC_ALL, language)
gloc = locale.getlocale()
record = t(language, sloc, gloc)
if gloc[0][2] == "_":
d["unix-like"].append(record)
else:
d["windows-like"].append(record)
 
pprint.pprint(dict(d))


n:\>C:\Miniconda3\python.exe N:\temp\loc.py
{'unix-like': [Locale(lang='french', setlocale='French_France.1252', 
getlocale=('fr_FR', 'cp1252')),
   Locale(lang='german', setlocale='German_Germany.1252', 
getlocale=('de_DE', 'cp1252')),
   Locale(lang='portuguese', setlocale='Portuguese_Brazil.1252', 
getlocale=('pt_BR', 'cp1252')),
   Locale(lang='spanish', setlocale='Spanish_Spain.1252', 
getlocale=('es_ES', 'cp1252'))],
 'windows-like': [Locale(lang='chinese', setlocale="Chinese 
(Simplified)_People's Republic of China.936", getlocale=("Chinese 
(Simplified)_People's Republic of China", '936')),
  Locale(lang='czech', setlocale='Czech_Czech Republic.1250', 
getlocale=('Czech_Czech Republic', '1250')),
  Locale(lang='danish', setlocale='Danish_Denmark.1252', 
getlocale=('Danish_Denmark', '1252')),
  Locale(lang='dutch', setlocale='Dutch_Netherlands.1252', 
getlocale=('Dutch_Netherlands', '1252')),
  Locale(lang='english', setlocale='English_United 
States.1252', getlocale=('English_United States', '1252')),
  Locale(lang='finnish', setlocale='Finnish_Finland.1252', 
getlocale=('Finnish_Finland', '1252')),
  Locale(lang='greek', setlocale='Greek_Greece.1253', 
getlocale=('Greek_Greece', '1253')),
  Locale(lang='hungarian', setlocale='Hungarian_Hungary.1250', 
getlocale=('Hungarian_Hungary', '1250')),
  Locale(lang='icelandic', setlocale='Icelandic_Iceland.1252', 
getlocale=('Icelandic_Iceland', '1252')),
  Locale(lang='italian', setlocale='Italian_Italy.1252', 
getlocale=('Italian_It

Re: Python 3 and the requests library

[Brian]

Zach,

Here is what I get on the Mac:

$ python3 -c "import token;print(token.__file__)" 
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/token.py

Just for grins, I also ran it against the built-in Python 2.7.5 version:

$ python -c "import token;print(token.__file__)" 
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/token.pyc

The only difference seems to be that the 2.7.5 version has precompiled it.

Then I followed your example but ran it against the logging module instead, as 
that seems to be where the problem lies. Again, for both version (broken 3 and 
working 2) as a comparison:

$ python3 -c "import logging;print(logging.__file__)" 
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/logging/__init__.py

$ python -c "import logging;print(logging.__file__)" 
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/logging/__init__.pyc

But nothing is pointing to anything except what appears to be the formally 
installed versions of these library modules.

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

Re: Python 3 and the requests library

[Zachary Ware]

On Mon, Feb 9, 2015 at 1:20 PM, Brian  wrote:
> I am also seeing this in my Mac Mavericks Python 3 installation when I use 
> just the built-in logging library. Again, a tiny example executable script 
> and the results:
>
> $ cat test2.py
> #!/usr/bin/env python3
> import logging
> logging.info("TEST2 starting")
>
> $ ./test2.py
> Traceback (most recent call last):
>   File "./test2.py", line 3, in 
> import logging
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/logging/__init__.py",
>  line 26, in 
> import sys, os, time, io, traceback, warnings, weakref, collections
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/traceback.py",
>  line 3, in 
> import linecache
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/linecache.py",
>  line 10, in 
> import tokenize
>   File 
> "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tokenize.py",
>  line 40, in 
> __all__ = token.__all__ + ["COMMENT", "tokenize", "detect_encoding",
> AttributeError: 'module' object has no attribute '__all__'
>
> Googling hasn't helped track this one down. In lieu of an answer, some 
> pointers to tools or other things to look for would be greatly appreciated. 
> Thanks!

Try this, from wherever test2.py lives:

python3 -c "import token;print(token.__file__)"

You should get back something akin to "/usr/lib64/python3.4/token.py"
(however that translates to Mac).  If instead you get the path to some
file of your own, rename your file.

Hope this helps,
-- 
Zach
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.x stuffing utf-8 into SQLite db

[Zachary Ware]

On Mon, Feb 9, 2015 at 11:32 AM, Skip Montanaro
 wrote:
> LibreOffice spit out a CSV file
> (with those three odd bytes). My script sucked in the CSV file and
> inserted data into my SQLite db.

If all else fails, you can try ftfy to fix things:
http://ftfy.readthedocs.org/en/latest/

   >>> import ftfy
   >>> ftfy.fix_text('Anderson Barracuda Masters - 2010 St.
Patrick’s Day Swim Meet')
   "Anderson Barracuda Masters - 2010 St. Patrick's Day Swim Meet"

It also seems to agree that there was a bad (en|de)coding with cp1252
at some point.

   >>> ftfy.fixes.fix_encoding_and_explain('Anderson Barracuda Masters
- 2010 St. Patrick’s Day Swim Meet')
   ('Anderson Barracuda Masters - 2010 St. Patrick’s Day Swim Meet',
[('encode', 'sloppy-windows-1252'), ('decode', 'utf-8')])

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

Re: Python 3.x stuffing utf-8 into SQLite db

[mm0fmf]

On 09/02/2015 03:44, Skip Montanaro wrote:

I am trying to process a CSV file using Python 3.5 (CPython tip as of a
week or so ago). According to chardet[1], the file is encoded as utf-8:

 >>> s = open("data/meets-usms.csv", "rb").read()
 >>> len(s)
562272
 >>> import chardet
 >>> chardet.detect(s)
{'encoding': 'utf-8', 'confidence': 0.99}

so I created the reader like so:

 rdr = csv.DictReader(open(csvfile, encoding="utf-8"))

This seems to work. The rows are read and records added to a SQLite3
database. When I go into sqlite3, I get what looks to be raw utf-8 on
output:

% LANG=en_US.UTF-8 sqlite3 topten.db
SQLite version 3.8.5 2014-08-15 22:37:57
Enter ".help" for usage hints.
sqlite> select * from swimmeet where meetname like '%Barracuda%';
sqlite> select count(*) from swimmeet;
0
sqlite> select count(*) from swimmeet;
4171
sqlite> select meetname from swimmeet where meetname like
'%Barracuda%Patrick%';
Anderson Barracudas St. Patrick's Day Swim Meet
Anderson Barracuda Masters - 2010 St. Patrick’s Day Swim Meet
Anderson Barracuda Masters 2011 St. Patrick’s Day Swim Meet
Anderson Barracuda Masters St. Patrick's Day Meet
Anderson Barracuda Masters St. Patrick's Day Meet 2014
Anderson Barracuda Masters 2015 St. Patrick’s Day Swim Meet



How is meetname defined? Is it a varchar or nvarchar?

My only experience is with MS-SQL and C# but reading from a utf-8 
encoded file with a StreamReader set to utf-8 and trying to insert that 
into varchar fields results in similar issues to what you are showing. I 
changed to using nvarchar and it all start working as expected.




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

Re: __next__ and StopIteration

[Rob Gaddi]

On Mon, 09 Feb 2015 11:14:55 -0800, Charles Hixson wrote:

> I'm trying to write a correct iteration over a doubly indexed container,
> and what I've got so far is:def __next__ (self):
>  for rowinrange(self._rows):
>  for col in range(self._cols):
>  if self._grid[row][col]:
>  yieldself._grid[row][col]
>  #endif
>  #endfor col
>  #endfor row raiseStopIteration
> 
> What bothers me is that it doesn't look like it would continue to raise
> StopIteration if it were called again, which is what
> https://docs.python.org/3/library/stdtypes.html#iterator.__next__ says
> is correct.  How should this be fixed?

You're mixing metaphors.  You don't iterate over containers, you iterate 
over iterators that are returned to you by containers.  So the container 
class itself has a __iter__ method, which returns a custom iterator 
object that has a __next__ method.  Which is a lot of work.

Or, you write your __iter__ like so:

def __iter__ (self):
for row in range(self._rows):
for col in range(self._cols):
if self._grid[row][col]:
yield self._grid[row][col]

In which case, Python's magic handling of yield handles the creation of 
the iterator object and the raising of StopIteration at the end of the 
__iter__ function all by itself.

Or you write your __iter__ like so:

def __iter__(self):
return (self._grid[row][col]
for col in range(self._cols)
for row in range(self._rows)
if self._grid[row][col]
)

In which case you've returned a generator expression, which is a 
shorthand way of making an iterator.  All extremely equivalent and a 
matter of personal taste (I'd probably opt for the yield one myself).

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 and the requests library

[Brian]

I am also seeing this in my Mac Mavericks Python 3 installation when I use just 
the built-in logging library. Again, a tiny example executable script and the 
results:

$ cat test2.py
#!/usr/bin/env python3
import logging
logging.info("TEST2 starting")

$ ./test2.py
Traceback (most recent call last):
  File "./test2.py", line 3, in 
import logging
  File 
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/logging/__init__.py",
 line 26, in 
import sys, os, time, io, traceback, warnings, weakref, collections
  File 
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/traceback.py", 
line 3, in 
import linecache
  File 
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/linecache.py", 
line 10, in 
import tokenize
  File 
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tokenize.py", 
line 40, in 
__all__ = token.__all__ + ["COMMENT", "tokenize", "detect_encoding",
AttributeError: 'module' object has no attribute '__all__'

Googling hasn't helped track this one down. In lieu of an answer, some pointers 
to tools or other things to look for would be greatly appreciated. Thanks!

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

Re: __next__ and StopIteration

[Ned Batchelder]

On 2/9/15 2:14 PM, Charles Hixson wrote:

I'm trying to write a correct iteration over a doubly indexed container,
and what I've got so far is:def __next__ (self):
 for rowinrange(self._rows):
 for col in range(self._cols):
 if self._grid[row][col]:
 yieldself._grid[row][col]
 #endif
 #endfor col
 #endfor row
 raiseStopIteration

What bothers me is that it doesn't look like it would continue to raise
StopIteration if it were called again, which is what
https://docs.python.org/3/library/stdtypes.html#iterator.__next__ says
is correct.  How should this be fixed?


You are using yield, which means __next__ is a generator.  As such, you 
don't have to explicitly raise StopIteration at all.  Just remove that 
statement, and you should be fine.


Also, look into how you are posting, the code is nearly mangled. :(

--
Ned Batchelder, http://nedbatchelder.com

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

__next__ and StopIteration

[Charles Hixson]

I'm trying to write a correct iteration over a doubly indexed container, 
and what I've got so far is:def __next__ (self):

for rowinrange(self._rows):
for col in range(self._cols):
if self._grid[row][col]:
yieldself._grid[row][col]
#endif
#endfor col
#endfor row
raiseStopIteration

What bothers me is that it doesn't look like it would continue to raise 
StopIteration if it were called again, which is what 
https://docs.python.org/3/library/stdtypes.html#iterator.__next__ says 
is correct.  How should this be fixed?

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

WHO IS PROPHET MUHAMMAD, MAY PEACE AND BLESSINGS BE UPON HIM?

[BV BV]

WHO IS PROPHET MUHAMMAD, MAY PEACE AND BLESSINGS BE UPON HIM?
 
He is the one who defended the rights of all humanity 1400 years ago
He defended men's, women's and children rights
He commanded and fostered the love between relatives and neighbors
He established a coexistence relationship between Muslims and Non-Muslims
He organized the relationship between the members of the family putting duties 
on sons and daughters towards the parents
He fought injustice, called for justice, love, unity and cooperation for the 
good.
He called for helping the needy, visiting the patients, love and exchanging 
advises between people.
He prohibited (by orders from God) bad manners such as stealing, lying, 
torturing and murdering.
He is the one who changed our lives and manners to be better.
A Muslim doesn't steal
A Muslim doesn't lie
A Muslim doesn't drink alcohol.
A Muslim doesn't commit adultery
A Muslim doesn't cheat
A Muslim doesn't kill innocent people
A Muslim doesn't harm his neighbors
A Muslim obeys his parents and helps them
A Muslim is kind to young and elderly people, to women and to weak people.
A Muslim doesn't torture humans or even animals, and does not harm trees
A Muslim loves his wife and takes care of his children and show mercy towards 
them until the last day of his life.
A Muslim's relationship towards his children never stops even when they become 
adults
He is Muhammad (PBUH)
Did you know why all Muslims love Muhammad (PBUH)?
Did you know what does Muhammad mean for Muslims?
Every Muslim loves Muhammad (peace be upon him) more than himself and more than 
everything in his life.
Before judging a Muslim be fair and:
1-Listen to this person, and watch his doings.
2-Compare his ideas and teachings with what is Islam and Prophet Mohammad PBUH 
ordered.
3-If you think that his thoughts are typical to that of Islam and
Prophet Mohammad PBUH, and then compare them with his doings; is he
applying these teachings?
4-If he is applying these teachings and sayings, so for sure represents
Islam, if not then he calls himself a Muslim but doesn't represent
Islam.
Mohammed Ansan and far from extremism and lying which has marketed
We as Muslims we publish a genuine people's love you oh Lord weiamhamd
 
Than you
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Please help.

[John Ladasky]

On Monday, February 9, 2015 at 10:26:47 AM UTC-8, Dave Angel wrote:

> That will help him with the functions.  But not with the keywords.  The 
> OP didn't specify Python version, but in 3.x, print() is a function, and 
> can be rebound.  Since he said keyword, he's either mistaken, or he's 
> running 2.x
> 
> But any real keywords, are a real problem.  For example, changing 'if' 
> to some other string.

That's true, Dave, he did say "key words".  I only helped him with his example 
of a Python built-in function.  And you're right, shadowing key words is 
currently not possible.

Are you familiar with a program known as a "talk filter"?  They've been around 
for decades.  

http://www.hyperrealm.com/talkfilters/talkfilters.html

Talk filters are usually used for off-color humor, rather than for serious 
purposes.  A talk filter processes a text stream, line-by-line, typically in a 
chat room setting.  A dictionary of words, and their replacements, is defined.  

I could see a talk filter being used to translate a non-English version of 
Python into standard English Python code.  I suppose that a hook for a talk 
filter could be added to the interpreter itself.  It wouldn't be easy to change 
word order to accommodate the syntax of another language, but words themselves 
could be altered.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Please help.

[Dave Angel]

On 02/09/2015 01:08 PM, John Ladasky wrote:

On Monday, February 9, 2015 at 9:44:16 AM UTC-8, chim...@gmail.com wrote:

Hello. Am trying to change the key words to my tribal language. Eg change 
English language: print() to igbo language: de(). I have been stuck for months 
I need a mentor or someone that can guide me and answer some of my questions 
when I get stuck. Thanks..
I will really appreciate it if someone attends to me.



In Python, functions are bound to names, exactly like other variables are.  You 
can bind any new name you want to an existing function, like this:

Python 3.4.0 (default, Apr 11 2014, 13:05:11)
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.

print("English")

English

de = print
de("Igbo")

Igbo

print("Both function names work")

Both function names work

de("Both function names work")

Both function names work


Hope that helps you.



That will help him with the functions.  But not with the keywords.  The 
OP didn't specify Python version, but in 3.x, print() is a function, and 
can be rebound.  Since he said keyword, he's either mistaken, or he's 
running 2.x


But any real keywords, are a real problem.  For example, changing 'if' 
to some other string.


And all the library code is a problem, as they have to be individually 
translated.  And many of them are not fully in Python, but have C portions.


Then there's the return strings for exceptions, and file names for imports.

And the documentation, and the inline documentation, and reflection.

Many problems, no good solutions.  It has been considered many times by 
many good Python developers, and no reasonable solution has presented 
itself.


When I use grep at the bash command line, do I want these translated to 
English words.  Nope.  They both are acronyms, but few people know what 
they actually stand for.


I wish there were an answer, but I don't think so, other than using a 
non-language (like Esperanto) to pick all the keywords and library 
functions of a new language in.  Then that new language would be equally 
hard for all nationalities to learn.


http://legacy.python.org/workshops/1997-10/proceedings/loewis.html

http://grokbase.com/t/python/python-list/09bsr7hjwh/python-statements-keyword-localization



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

Re: How to extract a movie title out of a text file

[sohcahtoa82]

On Saturday, February 7, 2015 at 8:54:26 AM UTC-8, Seymore4Head wrote:
> What I would like to be able to do is download and save to a folder
> all the srr files in this Usenet group.  alt.binaries.moovee
> 
> I would then like to be able to search for a title in the text file.
> 
> Anyone care to come up with the Python code to do this?

This guy's posts are always good for a laugh.  I hadn't seen one in a while and 
I was starting to miss them.
-- 
https://mail.python.org/mailman/listinfo/python-list

Python 3 and the requests library

[Brian]

On the Mac running Mavericks, I have successfully managed to install and use 
the requests library for HTTP and HTTPS requests using Python 2. But I'd like 
to move to Python 3.

I downloaded the most recent stable version of Python 3 for Mac. All is well. I 
did a pip3 install requests command and it worked. I could then start the 
interpreter and perform a simple HTTP GET request:

$ python3
Python 3.4.2 (v3.4.2:ab2c023a9432, Oct  5 2014, 20:42:22) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
>>> r = requests.get("http://www.google.com";)
>>> r


So, with that success, I created an executable script filled with the same 
commands:

#!/usr/bin/env python3
import requests
r = requests.get("http://www.google.com";)
print(r)

At first it failed because it couldn't find httplib2. Not sure why, but I 
installed httplib2 and now get the following error:

$ ./test.py
Traceback (most recent call last):
  File "test.py", line 3, in 
import requests
  File 
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/requests/__init__.py",
 line 53, in 
from .packages.urllib3.contrib import pyopenssl
  File 
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/requests/packages/__init__.py",
 line 3, in 
from . import urllib3
  File 
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/requests/packages/urllib3/__init__.py",
 line 10, in 
from .connectionpool import (
  File 
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py",
 line 2, in 
import logging
  File 
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/logging/__init__.py",
 line 26, in 
import sys, os, time, io, traceback, warnings, weakref, collections
  File 
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/traceback.py", 
line 3, in 
import linecache
  File 
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/linecache.py", 
line 10, in 
import tokenize
  File 
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tokenize.py", 
line 40, in 
__all__ = token.__all__ + ["COMMENT", "tokenize", "detect_encoding",
AttributeError: 'module' object has no attribute '__all__'

Here is the full list of installed packages that I have in python3 (the list in 
python2 is huge and not posted here):

$ pip3 list
httplib2 (0.9)
pip (1.5.6)
requests (2.5.1)
setuptools (2.1)
urllib3 (1.10)

Notre that if I change python3 to python in my script, it works fine using the 
default Python 2.7.5 version. And as a Plan B I can stay with Python 2.7.5. But 
I'd really like to move to Python 3 on the Mac.

Thanks in advance for any thoughts or help!

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

Re: Please help.

[John Ladasky]

On Monday, February 9, 2015 at 9:44:16 AM UTC-8, chim...@gmail.com wrote:
> Hello. Am trying to change the key words to my tribal language. Eg change 
> English language: print() to igbo language: de(). I have been stuck for 
> months I need a mentor or someone that can guide me and answer some of my 
> questions when I get stuck. Thanks..
> I will really appreciate it if someone attends to me.


In Python, functions are bound to names, exactly like other variables are.  You 
can bind any new name you want to an existing function, like this:

Python 3.4.0 (default, Apr 11 2014, 13:05:11) 
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print("English")
English
>>> de = print
>>> de("Igbo")
Igbo
>>> print("Both function names work")
Both function names work
>>> de("Both function names work")
Both function names work


Hope that helps you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.x stuffing utf-8 into SQLite db

[Matthew Ruffalo]

On 02/09/2015 12:30 PM, Skip Montanaro wrote:
> Thanks, Chris. Are you telling me I should have defined the input file
> encoding for my CSV file as CP-1252, or that something got hosed on
> the export from XLSX to CSV? Or something else?
>
> Skip

Hi Skip-

I think it's most likely that the encoding issues happened in the export
from XLSX to CSV (unless the data is malformed in the original XLSX
file, of course). The file you're reading *is* valid UTF-8, and you're
reading it in text mode, so seeing '’' in certain lines implies that
the files might contain '’'.encode('utf-8') ==
b'\xc3\xa2\xe2\x82\xac\xe2\x84\xa2'. You could verify this with a hex
editor, or use something like the following:

"""
#!/usr/bin/env python3
from argparse import ArgumentParser

   

def
dump_lines_with_high_bytes(filename):   
   

with open(filename, 'rb') as
f:  
  

for line in
f:  
   

if any(byte >= 0x80 for byte in
line): 
   
print(line) 
   


if __name__ == '__main__':
p = ArgumentParser()
p.add_argument('filename')
args = p.parse_args()
dump_lines_with_high_bytes(args.filename)
"""

I'm a bit surprised that LibreOffice would mangle the encoding like this
-- the entire point of using a format like XLSX is to avoid encoding
issues. I just created a blank spreadsheet with Excel 2013 on Windows 7,
pasted a U+2019 RIGHT SINGLE QUOTATION MARK into the top-left cell,
saved it to a .xlsx file, and opened it with LibreOffice Calc 4.2.7.2 on
Linux. The quot character displayed correctly, and I was able to save it
to valid UTF-8 CSV that I could read with Python 3.4 without any mojibake.

I wonder whether the encoding problems happened with whatever data was
used to create your .xlsx file -- as Chris mentioned, this would occur
if UTF-8 bytes are incorrectly decoded as Windows cp1252.

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

Please help.

[chimex60]

 ‎Hello. Am trying to change the key words to my tribal language. Eg change English language: print() to igbo language: de(). I have been stuck for months I need a mentor or someone that can guide me and answer some of my questions when I get stuck. Thanks..I will really appreciate it if someone attends to me.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3.x stuffing utf-8 into SQLite db

[Chris Angelico]

On Tue, Feb 10, 2015 at 4:32 AM, Skip Montanaro
 wrote:
> On Sun, Feb 8, 2015 at 10:51 PM, Steven D'Aprano
>  wrote:
>> The second question is, are you
>> using Windows?
>
> No, I'm on a Mac (as, I think I indicated in my original note). All
> transformations occurred on a Mac. LibreOffice spit out a CSV file
> (with those three odd bytes). My script sucked in the CSV file and
> inserted data into my SQLite db.

Did the file originally come from Windows, or was it always on a Mac?

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

Re: Python 3.x stuffing utf-8 into SQLite db

[Chris Angelico]

On Tue, Feb 10, 2015 at 4:30 AM, Skip Montanaro
 wrote:
> On Sun, Feb 8, 2015 at 9:58 PM, Chris Angelico  wrote:
>> Those three characters are the CP-1252 decode of the bytes for U+2019
>> in UTF-8 (E2 80 99). Not sure if that helps any, but given that it was
>> an XLSX file, Windows codepages are reasonably likely to show up.
>
> Thanks, Chris. Are you telling me I should have defined the input file
> encoding for my CSV file as CP-1252, or that something got hosed on
> the export from XLSX to CSV? Or something else?
>
> Skip

Well, I'm not entirely sure. If your input file is actually CP-1252
and you try to decode it as UTF-8, you'll almost certainly get an
error (unless of course it's all ASCII, but you know it isn't in this
case). Also, I'd say chardet will be correct. But it might be worth
locating one of those apostrophes in the file and looking at the
actual bytes representing it... because what you may have is a crazy
double-encoded system. If you take a document with U+2019 in it and
encode it UTF-8, then decode it as CP-1252, then re-encode as UTF-8,
you could get that. (I think. Haven't actually checked.) If someone
gave UTF-8 bytes to a program that doesn't know the difference between
bytes and characters, and assumes CP-1252, then you might well get
something like this. Hence, having a look at the exact bytes in the
.CSV file may help.

Easiest might be to pull it up in a hex viewer (I use 'hd' on my
Debian systems), and grep for the critical line. Otherwise, use Python
and try to pull out a line from the byte stream.

Good luck. You may need it.

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

Re: Python 3.x stuffing utf-8 into SQLite db

[Skip Montanaro]

On Sun, Feb 8, 2015 at 10:51 PM, Steven D'Aprano
 wrote:
> The second question is, are you
> using Windows?

No, I'm on a Mac (as, I think I indicated in my original note). All
transformations occurred on a Mac. LibreOffice spit out a CSV file
(with those three odd bytes). My script sucked in the CSV file and
inserted data into my SQLite db.

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

Re: Python 3.x stuffing utf-8 into SQLite db

[Skip Montanaro]

On Sun, Feb 8, 2015 at 9:58 PM, Chris Angelico  wrote:
> Those three characters are the CP-1252 decode of the bytes for U+2019
> in UTF-8 (E2 80 99). Not sure if that helps any, but given that it was
> an XLSX file, Windows codepages are reasonably likely to show up.

Thanks, Chris. Are you telling me I should have defined the input file
encoding for my CSV file as CP-1252, or that something got hosed on
the export from XLSX to CSV? Or something else?

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

ANN: Wing IDE 5.1.1 released

[Wingware]

Hi,

Wingware has released version 5.1.1 of Wing IDE, our cross-platform 
integrated development environment for the Python programming language.


Wing IDE features a professional code editor with vi, emacs, visual 
studio, and other key bindings, auto-completion, call tips, 
context-sensitive auto-editing, goto-definition, find uses, refactoring, 
a powerful debugger, version control, unit testing, search, project 
management, and many other features.


This minor release includes the following improvements:

Improve Django support when settings is a package and not a module
Preference to reuse existing instances of Wing when not otherwise 
specified

Added documentation on backing up and sharing settings
Only convert indents if pasting at start of line
Fix auto-completion with double-click on Windows
Fix restarting a debug session started with a Named Entry Point
Fix autocomplete after a blank line in Python Shell and Debug Probe
Keep editor scroll position the same when Replace All
Fix color of current item highlight in the auto-completer
Apply configured run marker alpha to selection color in Call Stack
Fix auto-spacing around % in argument lists
About 12 other bug fixes; see 
http://wingware.com/pub/wingide/5.1.1/CHANGELOG.txt


What's New in Wing 5.1:

Wing IDE 5.1 adds multi-process and child process debugging, syntax 
highlighting in the shells, persistent time-stamped unit test results, 
auto-conversion of indents on paste, an XCode keyboard personality, 
support for Flask and Django 1.7, and many other minor features and 
improvements.  For details see http://wingware.com/news/2015-02-26


Free trial: http://wingware.com/wingide/trial
Downloads: http://wingware.com/downloads
Feature list: http://wingware.com/wingide/features
Sales: http://wingware.com/store/purchase
Upgrades: https://wingware.com/store/upgrade

Questions?  Don't hesitate to email us at supp...@wingware.com.

Thanks,

--

Stephan Deibel
Wingware | Python IDE

The Intelligent Development Environment for Python Programmers

wingware.com

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

Re: locale bug in Python 2.7, 3.3, 3.4 (Win7 64)?

[Mark Lawrence]

On 09/02/2015 15:43, Albert-Jan Roskam wrote:

Hi,

In the locale module we have:
* setlocale, the setter that also returns something
* getlocale, the getter that returns the OS-specific locale tuple (supposedly!)

* getdefaultlocale, the getter that always returns a unix locale tuple

Why are the getlocale() results below sometimes windows-like, sometimes 
unix-like?
It seems that I need to use setlocale(), with only the 'category' parameter, 
right?


ActivePython 3.3.2.0 (ActiveState Software Inc.) based on
Python 3.3.2 (default, Sep 16 2013, 23:11:39) [MSC v.1600 64 bit (AMD64)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.

import locale
locale.getlocale()

(None, None)   # because setocale has not been called yet


# works as expected


locale.setlocale(locale.LC_ALL, "")

'Dutch_Netherlands.1252'

locale.getlocale()

('Dutch_Netherlands', '1252')

# bug!>>> locale.setlocale(locale.LC_ALL, "german")
'German_Germany.1252'

locale.getlocale()

('de_DE', 'cp1252') # incorect, unix-like!



locale.setlocale(locale.LC_ALL, "German_Germany.1252")

'German_Germany.1252'

locale.getlocale()

('de_DE', 'cp1252') # incorect, unix-like!


# bug!


locale.setlocale(locale.LC_ALL, "spanish")

'Spanish_Spain.1252'

locale.getlocale()

('es_ES', 'cp1252')   # incorect, unix-like!


# works as expected

locale.setlocale(locale.LC_ALL, "italian")

'Italian_Italy.1252'

locale.getlocale()

('Italian_Italy', '1252')# correct!


# ... maybe more?


Regards,

Albert-Jan



There have been loads of bug reports on the issue tracker about locales. 
 I suggest that you take a look to see if there is an open issue about 
this problem.




~~

All right, but apart from the sanitation, the medicine, education, wine, public 
order, irrigation, roads, a

fresh water system, and public health, what have the Romans ever done for us?

~~



Those flaming Romans didn't get the locales right did they? :)

--
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: doc buglets?

[Mark Lawrence]

On 09/02/2015 11:28, Rustom Mody wrote:

Poking around in help() (python 3.4.2) I find

* PACKAGES
does not seem to have anything on packages
* DYNAMICFEATURES
seems to be some kind of footnote
* SPECIALATTRIBUTES
has 'bases' and 'subclasses'. It seems to me a more consistent naming
for OOP would be in order.  These are the OOP-metaphors I am familiar with
- superclass ↔ subclass
- base class ↔ derived class
- parent class ↔ child class

[Yeah if this is a bug its more than a docbug.
So no, I am not suggesting changing the actual attribute names which would be a
breaking change, just the stuff in help()
]



So raise an issue and attach a patch.

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

locale bug in Python 2.7, 3.3, 3.4 (Win7 64)?

[Albert-Jan Roskam]

Hi,

In the locale module we have:
* setlocale, the setter that also returns something
* getlocale, the getter that returns the OS-specific locale tuple (supposedly!)

* getdefaultlocale, the getter that always returns a unix locale tuple

Why are the getlocale() results below sometimes windows-like, sometimes 
unix-like?
It seems that I need to use setlocale(), with only the 'category' parameter, 
right?


ActivePython 3.3.2.0 (ActiveState Software Inc.) based on
Python 3.3.2 (default, Sep 16 2013, 23:11:39) [MSC v.1600 64 bit (AMD64)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getlocale()
(None, None)   # because setocale has not been called yet


# works as expected

>>> locale.setlocale(locale.LC_ALL, "")
'Dutch_Netherlands.1252'
>>> locale.getlocale()
('Dutch_Netherlands', '1252')

# bug!>>> locale.setlocale(locale.LC_ALL, "german")
'German_Germany.1252'
>>> locale.getlocale()
('de_DE', 'cp1252') # incorect, unix-like!


>>> locale.setlocale(locale.LC_ALL, "German_Germany.1252")
'German_Germany.1252'
>>> locale.getlocale()
('de_DE', 'cp1252') # incorect, unix-like!


# bug!

>>> locale.setlocale(locale.LC_ALL, "spanish")
'Spanish_Spain.1252'
>>> locale.getlocale()
('es_ES', 'cp1252')   # incorect, unix-like!


# works as expected
>>> locale.setlocale(locale.LC_ALL, "italian")
'Italian_Italy.1252'
>>> locale.getlocale()
('Italian_Italy', '1252')# correct!


# ... maybe more?

 
Regards,

Albert-Jan




~~

All right, but apart from the sanitation, the medicine, education, wine, public 
order, irrigation, roads, a 

fresh water system, and public health, what have the Romans ever done for us?

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

Re: How to Mock a mongodb

[Jean-Michel Pichavant]

- Original Message -
> From: "Xavier Pegenaute" 
> To: python-list@python.org
> Sent: Saturday, 7 February, 2015 11:09:10 PM
> Subject: How to Mock a mongodb
> 
> Dear,
> 
> I am trying to mock the use of a mongo db and I am having some
> trouble.
> Appears that I am not able to return a desired value from
> mongo.find().count(). I made a proof of concept to try to reduce
> complexity of the real problem.
> 
> You can find the code which is going to be tested in [1], and the
> code
> of the test case in [2].
> 
> Do you know exactly wat's wrong with it?, or may you point me to some
> direction?
> 
> Thanks,
> Xavi

You've mocked the pymongo.cursor but since you've mocked the entire mongo 
client, this mocked client will never return a pymongo.cursor, it will return 
only mock objects.

What you can do is mock the entire chain call of you mocked client:


from mock import patch
from mmongo import MongoHelper

class TestMongoHelper(object):

  @patch("mmongo.pymongo")
  def test_count_data(self, fake_mongo_client):
mhelper = MongoHelper()

# mock self.db[MongoHelper.db_name][MongoHelper.coll_name].find().count()

fake_mongo_client.__getitem__.return_value.__getitem__.return_value.find.return_value.count.return_value
 = 5


JM


-- IMPORTANT NOTICE: 

The contents of this email and any attachments are confidential and may also be 
privileged. If you are not the intended recipient, please notify the sender 
immediately and do not disclose the contents to any other person, use it for 
any purpose, or store or copy the information in any medium. Thank you.
-- 
https://mail.python.org/mailman/listinfo/python-list

doc buglets?

[Rustom Mody]

Poking around in help() (python 3.4.2) I find

* PACKAGES
does not seem to have anything on packages
* DYNAMICFEATURES
seems to be some kind of footnote
* SPECIALATTRIBUTES
has 'bases' and 'subclasses'. It seems to me a more consistent naming
for OOP would be in order.  These are the OOP-metaphors I am familiar with
- superclass ↔ subclass
- base class ↔ derived class
- parent class ↔ child class

[Yeah if this is a bug its more than a docbug.
So no, I am not suggesting changing the actual attribute names which would be a 
breaking change, just the stuff in help()
]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Profiler for long-running application

[Asad Dhamani]

On Monday, February 9, 2015 at 1:50:58 PM UTC+5:30, Ryan Stuart wrote:
> Hi Asad,
> 
> Is there any reason why you can't just use profile/cProfile? In particular, 
> you could use the api of that module to save out the profile stats to an 
> external file with a unique name and then inspect them later with a tool like 
> snakeviz. The code to save profile stats might look like the following:
> 
> 
>     pr = cProfile.Profile()
>     pr.runcall(your_celery_task_without_async)
>     ps = pstats.Stats(pr)
>     ps.dump_stats("my_task.profile")
> Obviously you need to call your celery task function directly, not via Celery 
> using delay() or any derivative. Alternatively, you could try something like 
> line_profiler by again, calling the task directly.
> 
> 
> If using this method it turn out your actual task code is running quite fast, 
> then I'd suggest that the majority of the time is being lost in transferring 
> the task to the Celery node.
> 
> Cheers
> 
> 
> On Mon Feb 09 2015 at 5:20:43 AM Asad Dhamani  wrote:
> I have a Flask application where I run a specific task asynchronously using 
> Celery. Its basically parsing some HTML and inserting data into a Postgres 
> database(using SQLAlchemy). However, the task seems to be running very 
> slowly, at 1 insert per second.
> 
> I'd like to find out where the bottleneck is, and I've been looking for a 
> good profiler that'd let me do this, however, I couldn't find anything. Any 
> recommendations would be great.
> 
> --
> 
> https://mail.python.org/mailman/listinfo/python-list

Hi  Ryan,

I was looking for something that didn't make me modify my code. It seems like 
I'll just use cProfile with snakeviz. 

Thanks for the help
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Profiler for long-running application

[Ryan Stuart]

Hi Asad,

Is there any reason why you can't just use profile/cProfile? In particular,
you could use the api of that module to save out the profile stats to an
external file with a unique name and then inspect them later with a tool
like snakeviz . The code to save
profile stats might look like the following:

pr = cProfile.Profile()
pr.runcall(your_celery_task_without_async)
ps = pstats.Stats(pr)
ps.dump_stats("my_task.profile")

Obviously you need to call your celery task function directly, not via
Celery using delay() or any derivative. Alternatively, you could try
something like line_profiler  by
again, calling the task directly.

If using this method it turn out your actual task code is running quite
fast, then I'd suggest that the majority of the time is being lost in
transferring the task to the Celery node.

Cheers

On Mon Feb 09 2015 at 5:20:43 AM Asad Dhamani  wrote:

> I have a Flask application where I run a specific task asynchronously
> using Celery. Its basically parsing some HTML and inserting data into a
> Postgres database(using SQLAlchemy). However, the task seems to be running
> very slowly, at 1 insert per second.
> I'd like to find out where the bottleneck is, and I've been looking for a
> good profiler that'd let me do this, however, I couldn't find anything. Any
> recommendations would be great.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list