Re: I'm wrong or Will we fix the ducks limp?

[Gregory Ewing]

Marko Rauhamaa wrote:
> [concerning leashed puppies]

Note: no boxes! However, there are strings attached. Now you can truly
*bind* objects to variables.


If you wanted to really bind them good and proper,
you'd use duct tape (or "duck tape" as some people
call it -- arguably more appropriate in this context!)


Seriously, though, it is notable that the high-level programming
languages pretty unanimously refuse to make variables first-class
objects. I wonder why.


That's an interesting question. One reason might be
that in the absence of static type analysis, assigning
to a variable holding a reference to another variable
would be ambiguous. For example, suppose Python had
an & operator that gives you an object referring to
a variable somehow. Then, after

a = 42
b = 17
c = &a
c = &b

does 'c' now hold a reference to the variable 'b', or
does it still hold a reference to 'a' and 'a' now
holds a reference to 'b'?

Somehow these two operations would have to be spelled
different ways, which means you would need to know
whether you were dealing with a variable reference or
not. So they wouldn't really be first-class, in the
sense of being treated on an equal footing with
ordinary variables.

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

Re: Recommendation for GUI lib?

[Nick Sarbicki]

>
> Qt Designer is certainly a good GUI builder, but not more than that.
> When you actually want to use the designed GUI in Python, you will find
> that this needs almost as much know how and work as if you did the GUI
> in code.
>

I think that's a bit of an unfair statement. Sure conversion can be a bit
of a pain and there is some setup for getting the classes working. But that
is generally a small static piece of code you can find all over the net,
which is then usable for most projects.

The code you get from Qt creator however can be a huge bulk of the work
which you thankfully don't need to nitpick over much at all.

Yes understanding how it works helps a lot and I'd recommend anyone to have
a look at how to build a decent GUI with Qt.

But for me, once past the understanding, coding GUIs by hand is about as
dull as it gets. Qt creator definitely makes the work go faster.

- Nick.

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

Re: for / while else doesn't make sense

[Lawrence D’Oliveiro]

On Tuesday, June 7, 2016 at 4:36:37 PM UTC+12, Ian wrote:
> A 500-line function? Yikes, what an eyesore. When you have to include
> #end comments in order to visually match things up, that should be a
> smell that your code is excessively complex.

Feel free to come up with a simpler version.

> def generate_lines():
> nonlocal input_line
> while True:
> try:
> # Note input_line appears to be an iterator, not a string
> # as suggested by the name.
> yield next(input_line)
> except StopIteration:
> if include_stack:
> input_line = include_stack.pop()
> else:
> return
> 
> for line in generate_lines():
> if not include_stack:
> linenr += 1
> if ... line contains something special ...:
> ... process special line ...
> else:
> ... process regular line ...

Wow, that’s only twice the length of the code you’re replacing. Well done.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[Lawrence D’Oliveiro]

On Tuesday, June 7, 2016 at 3:34:39 PM UTC+12, Dan Sommers wrote:

> I used to write a lot of assembly code, for a lot of different CPUs, and
> they all had a common, versatile looping form which could be arranged in
> different ways to suit the problem at hand.  On most chips, it was (and
> still is) called JMP.  The trouble began with multiple conditional
> branching, call stack maintenance, and those other higher level
> abstractions that made my assembly code so hard to follow.

You’ll notice I don’t use gotos in my code.

Next red-herring example, please...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Marko Rauhamaa]

Gregory Ewing :

> Marko Rauhamaa wrote:
>> Seriously, though, it is notable that the high-level programming
>> languages pretty unanimously refuse to make variables first-class
>> objects. I wonder why.
>
> That's an interesting question. One reason might be
> that in the absence of static type analysis, assigning
> to a variable holding a reference to another variable
> would be ambiguous. For example, suppose Python had
> an & operator that gives you an object referring to
> a variable somehow. Then, after
>
> a = 42
> b = 17
> c = &a
> c = &b
>
> does 'c' now hold a reference to the variable 'b', or
> does it still hold a reference to 'a' and 'a' now
> holds a reference to 'b'?

If variables were ordinary mutable objects, you'd need a syntax of
dereferencing, just like in C. Variable objects would be highly
analogous to single-element arrays, little boxes if you will.

> Somehow these two operations would have to be spelled different ways,
> which means you would need to know whether you were dealing with a
> variable reference or not. So they wouldn't really be first-class, in
> the sense of being treated on an equal footing with ordinary
> variables.

It's not that ambiguous.

   >>> a = 3
   >>> c = &a
   >>> c
   
   >>> *c
   3
   >>> c is a
   False
   >>> *c is a
   True
   >>> c is &a
   True
   >>> a = 4
   >>> *c
   4
   >>> *c is a
   True
   >>> c = &c
   >>> c
   
   >>> *c
   
   >>> **c
   


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

Re: for / while else doesn't make sense

[Marko Rauhamaa]

Lawrence D’Oliveiro :

> On Tuesday, June 7, 2016 at 4:36:37 PM UTC+12, Ian wrote:
>> A 500-line function? Yikes, what an eyesore. When you have to include
>> #end comments in order to visually match things up, that should be a
>> smell that your code is excessively complex.
>
> [...]
>
> Wow, that’s only twice the length of the code you’re replacing. Well
> done.

I understand you are hurt when your code is criticized bluntly. However,
you *did* stick your head out.

I, too, insist that every function/method must be visible at once in the
editor window.


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

Re: for / while else doesn't make sense

[Steven D'Aprano]

On Tuesday 07 June 2016 17:52, Lawrence D’Oliveiro wrote:

> On Tuesday, June 7, 2016 at 4:36:37 PM UTC+12, Ian wrote:
>> A 500-line function? Yikes, what an eyesore. When you have to include
>> #end comments in order to visually match things up, that should be a
>> smell that your code is excessively complex.
> 
> Feel free to come up with a simpler version.

If I could work out what your convoluted version is supposed to do, I might 
give it a try.

[...]

>> def generate_lines():
>> nonlocal input_line
[snip code]

> Wow, that’s only twice the length of the code you’re replacing. Well done.

I count 18 lines in your version using while loops, excluding comments, but 
including placeholder ... lines, compared to 17 lines in Ian's version. How do 
you get "twice the length"?

Ian's version is also much simpler: there are no breaks and no variables being 
assigned to None so you can detect the end of the loop, and only three `if`s 
instead of six in your version. That makes Ian's objectively less complex than 
your example, assuming it does the same thing. (Although I'm a bit dubious 
about the use of nonlocal.)



-- 
Steve

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

Re: I'm wrong or Will we fix the ducks limp?

[Jussi Piitulainen]

Marko Rauhamaa  writes:

> Gregory Ewing :
>
>> Marko Rauhamaa wrote:
>>> Seriously, though, it is notable that the high-level programming
>>> languages pretty unanimously refuse to make variables first-class
>>> objects. I wonder why.
>>
>> That's an interesting question. One reason might be
>> that in the absence of static type analysis, assigning
>> to a variable holding a reference to another variable
>> would be ambiguous. For example, suppose Python had
>> an & operator that gives you an object referring to
>> a variable somehow. Then, after
>>
>> a = 42
>> b = 17
>> c = &a
>> c = &b
>>
>> does 'c' now hold a reference to the variable 'b', or
>> does it still hold a reference to 'a' and 'a' now
>> holds a reference to 'b'?
>
> If variables were ordinary mutable objects, you'd need a syntax of
> dereferencing, just like in C. Variable objects would be highly
> analogous to single-element arrays, little boxes if you will.

I've had this little piece lying around ever since there last was a
discussion about assignments as expressions. It abuses the ** operator
to store values in boxes; the value of 'expression ** x' is the value of
'expression', with the side effect that afterwards the value of x.it
(the dereferencing!) is also whatever the value of 'expression' was.

class Box(object):
'''Read ** as as and x.it as whatever was saved as x.'''
def __init__(self, init = None):
self.it = init
def __rpow__(self, it): # f() ** self
self.it = it
return self.it

data = iter('piäsiäntösesti ee näen')
from string import ascii_letters as ascii

x, y = Box(), Box()
while (next(data) ** x in ascii and
   next(data) ** y in ascii):
print(x.it, y.it)
# Prints one line: p i

There's a further test case in that file, saving the regex match object
during the expression that tests whether there was a match object. Not
entirely satisfactory, but perhaps mildly interesting.

import re
beg = re.compile(r'start=(\w+)')
end = re.compile(r'finis=(\w+)')

b, e = Box(), Box()
for k, line in enumerate(('xxx',
  '# start=eka rivi',
  'ween',
  'ween',
  '# finis=vika rivi',
  'xxx')):
if not b.it and beg.search(line) ** b:
print(k, b.it.group(1))
elif b.it and end.search(line) ** e:
print(k, e.it.group(1))
break
elif b.it:
print(k, line)
# Prints four lines:
# 1 eka 
# 2 ween
# 3 ween
# 4 vika
-- 
https://mail.python.org/mailman/listinfo/python-list

How to implement semaphores in python?

[karthik jagilinki]

Hello All,

I need some help with semaphore implementation between two programs in python. 
I'd be glad if anyone can give me some help.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to implement semaphores in python?

[David Palao]

Hi,
Have you checked this
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Semaphore
?

Best

2016-06-07 11:43 GMT+02:00 karthik jagilinki :
> Hello All,
>
> I need some help with semaphore implementation between two programs in 
> python. I'd be glad if anyone can give me some help.
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Steven D'Aprano]

On Tuesday 07 June 2016 15:42, Gregory Ewing wrote:

> Steven D'Aprano wrote:
>> Even if you were right that objects must exist at
>> a single well-defined location, that is strictly irrelevant. That's
>> implementation, not interface.
> 
> We're talking about mental models. Sure, you could come up
> with some kind of Tardis-like mental model where objects
> exist in more than one location at once. But why would
> you bother going to such mental contortions?

Because (self-recursive data structures like lists that contain themselves 
aside), that's actually a much more simple mental model than the pointer model. 
Its how natural language works. Compare:

"Greg kicked the penguin."

with:

"The person whose name is Greg kicked the penguin."

Both say the same thing. The first uses the word 'Greg' as a direct stand-in 
for the person Greg himself, the man. 'Greg' (the word) is used to mean the 
person Greg, it is not used as "a word that refers to the person". 

The second emphasises the fact that 'Greg' is a name, not a person, and is a 
form of indirection. It uses 'Greg' as 'a word that refers to the person', not 
the person itself. We almost always prefer sentences of the first type rather 
than the second.

x = 999

Why should we say "x is a reference to 999" when "x is 999" is simpler, 
shorter, explains the semantics of the code, and is arguably more correct?

Given that in Python code, x behaves like an int, and looks like an int, and we 
treat it like an int, applying int operations such as + to it, and we discuss 
it as if it were an int, why on earth would we bother going to such mental 
contortions as to insist that its actually a reference?

Here's a thought experiment for you. Suppose in Python 3.6, Guido announces 
that Python will support a form of high-level pointer (not the scary, dangerous 
low-level pointer of C) called "reference". There will be a dereference 
operator, ^, and a "reference to" operator, @. We'll be able to treat 
references as first-class values:

x = 999
y = @x

print(y)
=> prints "ref --> 999"

print(type(y))
=> prints "reference"

print(y^ + 1)
=> prints 1000


Do we say:

"x is 999, and y is a reference to x"

or would you prefer:

"x is a reference to 999, and y is a reference to a reference to x"?


We users of languages like Python get all the advantages of references, dynamic 
allocation of variables, indirection etc. with none of the pain, or at least 
hardly any. We rarely need to care about the fact that the interpreter uses 
indirect references under the hood, because the Python language itself doesn't 
require us to care. When we assign "x = 999", we treat x as if it were an int, 
just like the code says it is. When we assign "x = []", we treat x as if it 
were a list, just like the code says. Why should we insist that x isn't 
actually an int, or a list, but an invisible, untouchable, unseen reference?


By the way, I believe that these people claiming that x is a reference do not, 
in general, use that language in real life. I would be willing to bet that you 
say "x is 999" just like I do.


-- 
Steve

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

Re: I'm wrong or Will we fix the ducks limp?

[BartC]

On 07/06/2016 08:56, Marko Rauhamaa wrote:

Gregory Ewing :


Marko Rauhamaa wrote:

Seriously, though, it is notable that the high-level programming
languages pretty unanimously refuse to make variables first-class
objects. I wonder why.


That's an interesting question. One reason might be
that in the absence of static type analysis, assigning
to a variable holding a reference to another variable
would be ambiguous. For example, suppose Python had
an & operator that gives you an object referring to
a variable somehow. Then, after

a = 42
b = 17
c = &a
c = &b

does 'c' now hold a reference to the variable 'b', or
does it still hold a reference to 'a' and 'a' now
holds a reference to 'b'?


c points to b. For the latter part of your statement to be true, the 
last line might have to be something like:


 *c = &b


Somehow these two operations would have to be spelled different ways,
which means you would need to know whether you were dealing with a
variable reference or not. So they wouldn't really be first-class, in
the sense of being treated on an equal footing with ordinary
variables.


It's not that ambiguous.

   >>> a = 3
   >>> c = &a
   >>> c
   
   >>> *c
   3
   >>> c is a
   False
   >>> *c is a
   True
   >>> c is &a
   True
   >>> a = 4
   >>> *c
   4
   >>> *c is a
   True
   >>> c = &c
   >>> c
   
   >>> *c
   
   >>> **c
   



Here are some results in another, non-Python language. While the object 
reference module is similar to Python's, the language retains explicit 
pointers which can be used for variable references.


In this code, ^x means pointer to x, x^ means dereference c, while := is 
assignment and = means equality:


a := 3
c := ^a

println c   # refvar: 02176228

println c = a   # error (compare pointer to int)
println c = ^a  # True

a := 4
println c^  # 4

c^ := 12
println a   # 12

c := ^c
println c   # refvar: 02176248
println c^  # refvar: 02176248
println c^^ # refvar: 02176248

Associating a pointer value to a variable symbol table entry is a 
separate step. But a pointer needn't point at just a named variable:


a := (10,20,30,40,50)
c := ^a[3]

println c^  # 30 (was 1-based)

c^ := 77
println a   # (10,20,77,40,50)


And here is the above example:

a := 42
b := 17
c := ^a
c^ := ^b

println a   # refvar: 21A16F0
println a^  # 17

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

reshape and keep x,y,z ordering

[Heli]

Hello, 

I have a question regarding reshaping numpy array. 

I either have a 1D array that I need to reshape to a 3D array or a 3D array to 
reshape to a 1d numpy array. 

In both of these cases it is assumed that data follows x,y,z ordering.

and I use the following to reshape the numpy array. 


new_1d_array=np.reshape(3d.transpose(),(3d_nx*3d_ny*3d_nz,)) 


new_3d_array=np.reshape(1d,((3d_x,3d_y,3d_z)).transpose())

My question is if there is anyway that reshape would keep x,y,z ordering that 
would not require transpose? and if there is a better more efficient way to do 
this?

Thanks alot, 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[Ian Kelly]

On Tue, Jun 7, 2016 at 1:52 AM, Lawrence D’Oliveiro
 wrote:
> Wow, that’s only twice the length of the code you’re replacing. Well done.

Huh? The example that you posted was 17 lines, excluding comments. My
replacement code is 17 lines, excluding comments. Where are you
getting "twice the length" from?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xlrd 1.0.0 released!

[derek]

Gmail and the Gmail Digest only ever show the 0.9.4 tag - not sure if this 
a big issue or not (but I know I would like to the 1.0.0 tag to be proudly 
displayed!)

On Friday, 3 June 2016 03:57:35 UTC+2, Chris Withers wrote:
>
> Ugh, and once again, this time with a corrected title... 
>
>
> On 02/06/2016 18:56, Chris Withers wrote: 
> > Hi All, 
> > 
> > Well, I've finally called it and tagged current master of xlrd as 1.0.0: 
> > 
> > http://pypi.python.org/pypi/xlrd/1.0.0 
> > 
> > This release includes the following changes since the last release: 
> > 
> > - Official support, such as it is, is now for 2.6, 2.7, 3.3+ 
> > 
> > - Fixes a bug in looking up non-lowercase sheet filenames by ensuring 
> > that the sheet targets are transformed the same way as the 
> > component_names dict keys. 
> > 
> > - Fixes a bug for ragged_rows=False when merged cells increases the 
> > number of columns in the sheet. This requires all rows to be extended 
> > to ensure equal row lengths that match the number of columns in the 
> > sheet. 
> > 
> > - Fixes to enable reading of SAP-generated .xls files. 
> > 
> > - support BIFF4 files with missing FORMAT records. 
> > 
> > - support files with missing WINDOW2 record. 
> > 
> > - Empty cells are now always unicode strings, they were a bytestring 
> > on Python2 and a unicode string on Python3. 
> > 
> > - Fix for  inlineStr attribute without  child. 
> > 
> > - Fix for a zoom of None causes problems on Python 3. 
> > 
> > - Fix parsing of bad dimensions. 
> > 
> > - Fix xlsx sheet->comments relationship. 
> > 
> > Thanks to the following for their contributions to this release: 
> > 
> > - Lars-Erik Hannelius 
> > - Deshi Xiao 
> > - Stratos Moro 
> > - Volker Diels-Grabsch 
> > - John McNamara 
> > - Ville Skyttä 
> > - Patrick Fuller 
> > - Dragon Dave McKee 
> > - Gunnlaugur Þór Briem 
> > 
> > If you find any problems, please ask about them on the 
> > python...@googlegroups.com  list, or submit an issue on 
> GitHub: 
> > 
> > https://github.com/python-excel/xlrd/issues 
> > 
> > Full details of all things Python and Excel related can be found here: 
> > 
> > http://www.python-excel.org/ 
> > 
> > NB: If you would like to become the maintainer of xlwt, please get in 
> > touch! Neither myself nor John Machin have much time to drive things 
> > forward nowadays, hence the year or so between each release... 
> > 
> > cheers, 
> > 
> > Chris 
> > 
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[Dan Sommers]

On Tue, 07 Jun 2016 00:53:31 -0700, Lawrence D’Oliveiro wrote:

> On Tuesday, June 7, 2016 at 3:34:39 PM UTC+12, Dan Sommers wrote:
> 
>> I used to write a lot of assembly code, for a lot of different CPUs, and
>> they all had a common, versatile looping form which could be arranged in
>> different ways to suit the problem at hand.  On most chips, it was (and
>> still is) called JMP.  The trouble began with multiple conditional
>> branching, call stack maintenance, and those other higher level
>> abstractions that made my assembly code so hard to follow.
> 
> You’ll notice I don’t use gotos in my code.

I notice plenty of break statements scattered throughout your loop
bodies.  Mixing the loop's exit conditions in with the logic is equally
unstructured.

> Next red-herring example, please...

I didn't say anything about a red-herring.  Please stick to the topic at
hand.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Antoon Pardon]

Op 07-06-16 om 12:18 schreef Steven D'Aprano:
> We're talking about mental models. Sure, you could come up
> with some kind of Tardis-like mental model where objects
> exist in more than one location at once. But why would
> you bother going to such mental contortions?
> Because (self-recursive data structures like lists that contain themselves 
> aside), that's actually a much more simple mental model than the pointer 
> model. 
> Its how natural language works. Compare:
>
> "Greg kicked the penguin."
>
> with:
>
> "The person whose name is Greg kicked the penguin."
>
> Both say the same thing. The first uses the word 'Greg' as a direct stand-in 
> for the person Greg himself, the man. 'Greg' (the word) is used to mean the 
> person Greg, it is not used as "a word that refers to the person". 
>
> The second emphasises the fact that 'Greg' is a name, not a person, and is a 
> form of indirection. It uses 'Greg' as 'a word that refers to the person', 
> not 
> the person itself. We almost always prefer sentences of the first type rather 
> than the second.

Yes almost. But the second is more accurate and sometimes the extra accuracy
matters. Like often enough the difference between numbers and numerals when 
people
say they want to work with binary numbers.

> x = 999
>
> Why should we say "x is a reference to 999" when "x is 999" is simpler, 
> shorter, explains the semantics of the code, and is arguably more correct?
>
> Given that in Python code, x behaves like an int, and looks like an int, and 
> we 
> treat it like an int, applying int operations such as + to it, and we discuss 
> it as if it were an int, why on earth would we bother going to such mental 
> contortions as to insist that its actually a reference?

Because you are putting blinders on by only looking at a simple type like an 
int.
By looking only at ints, you are totally obscuring the difference in asignment
semantics beween C and python. And by obscuring that difference you are inviting
the confused inquiries later, on whether argument passing in python is by value 
or
by reference.

Sure talk about "x is 999" when you are talking about a piece of code, but when
you are explaining assignment semantics or other particulars of the language
saying things like that is taking a shortcut that often enough will cause
confusions later.

> Here's a thought experiment for you. Suppose in Python 3.6, Guido announces 
> that Python will support a form of high-level pointer (not the scary, 
> dangerous 
> low-level pointer of C) called "reference". There will be a dereference 
> operator, ^, and a "reference to" operator, @. We'll be able to treat 
> references as first-class values:

That makes very little sense in python.  

> We users of languages like Python get all the advantages of references, 
> dynamic 
> allocation of variables, indirection etc. with none of the pain, or at least 
> hardly any. We rarely need to care about the fact that the interpreter uses 
> indirect references under the hood, because the Python language itself 
> doesn't 
> require us to care. When we assign "x = 999", we treat x as if it were an 
> int, 
> just like the code says it is. When we assign "x = []", we treat x as if it 
> were a list, just like the code says. Why should we insist that x isn't 
> actually an int, or a list, but an invisible, untouchable, unseen reference?

That doesn't change the fact that when you have to explain the language 
semantics,
making it clear that variables are essentials references and that an assigment
just changes such a reference and doesn't do a copy.

> By the way, I believe that these people claiming that x is a reference do 
> not, 
> in general, use that language in real life. I would be willing to bet that 
> you 
> say "x is 999" just like I do.

So what? People use shortcuts in language all the time, because often enough the
context makes it clear how the shortcut is to be understood. That people often
use the shortcut "x is 999" doesn't make the statement wrong that variables are
essentially references in Python. 

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

Re: reshape and keep x,y,z ordering

[Joel Goldstick]

On Tue, Jun 7, 2016 at 7:25 AM, Heli  wrote:
> Hello,
>
> I have a question regarding reshaping numpy array.
>
> I either have a 1D array that I need to reshape to a 3D array or a 3D array 
> to reshape to a 1d numpy array.
>
> In both of these cases it is assumed that data follows x,y,z ordering.
>
> and I use the following to reshape the numpy array.
>
>
> new_1d_array=np.reshape(3d.transpose(),(3d_nx*3d_ny*3d_nz,))
>
>
> new_3d_array=np.reshape(1d,((3d_x,3d_y,3d_z)).transpose())
>
> My question is if there is anyway that reshape would keep x,y,z ordering that 
> would not require transpose? and if there is a better more efficient way to 
> do this?
>
> Thanks alot,
> --
> https://mail.python.org/mailman/listinfo/python-list

Sorry, I can't help, others may be able to help you here.  But there
is also a numpy specific mailing list you might try

-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: reshape and keep x,y,z ordering

[Michael Selik]

On Tue, Jun 7, 2016 at 7:31 AM Heli  wrote:

> Hello,
> I have a question regarding reshaping numpy array.
>
> I either have a 1D array that I need to reshape to a 3D array or a 3D
> array to reshape to a 1d numpy array.
>
> In both of these cases it is assumed that data follows x,y,z ordering.
> and I use the following to reshape the numpy array.
>
> new_1d_array=np.reshape(3d.transpose(),(3d_nx*3d_ny*3d_nz,))
>
> new_3d_array=np.reshape(1d,((3d_x,3d_y,3d_z)).transpose())
>
> My question is if there is anyway that reshape would keep x,y,z ordering
> that would not require transpose? and if there is a better more efficient
> way to do this?


>>> a = np.arange(9).reshape(3,3)
>>> a
array([[0, 1, 2],
   [3, 4, 5],
   [6, 7, 8]])
>>> a.flatten()
array([0, 1, 2, 3, 4, 5, 6, 7, 8])
>>> a.flatten('F')
array([0, 3, 6, 1, 4, 7, 2, 5, 8])

Does this work for you?
The flatten method normally goes row by row, but you can specify FORTRAN
style column by column flattening.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: reshape and keep x,y,z ordering

[Heli]

Thanks Michael, 

This did the trick. array.flatten('F') works exactly as I need. 

Thanks a lot, 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Random832]

On Tue, Jun 7, 2016, at 03:03, Gregory Ewing wrote:
> a = 42
> b = 17
> c = &a
> c = &b
> 
> does 'c' now hold a reference to the variable 'b', or
> does it still hold a reference to 'a' and 'a' now
> holds a reference to 'b'?

It'd have to be spelled *c = &b, or c.value = &b or c.setvalue(&b), or
something like that, to mean the latter.

> Somehow these two operations would have to be spelled
> different ways, which means you would need to know
> whether you were dealing with a variable reference or
> not. So they wouldn't really be first-class, in the
> sense of being treated on an equal footing with
> ordinary variables.

Er, how would that make them not first class? Lots of operations need to
be spelled differently, that's why we have so many operators, attribute
lookup syntax, etc. "Assign to the variable object that is in this
variable" would be a distinct operation from "Assign to this variable",
just like "add one to this value" or "call this function" etc.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Random832]

On Tue, Jun 7, 2016, at 08:32, Antoon Pardon wrote:
> > Here's a thought experiment for you. Suppose in Python 3.6, Guido announces 
> > that Python will support a form of high-level pointer (not the scary, 
> > dangerous 
> > low-level pointer of C) called "reference". There will be a dereference 
> > operator, ^, and a "reference to" operator, @. We'll be able to treat 
> > references as first-class values:
> 
> That makes very little sense in python.  

Why not? If you prefer, think of it something like:

class ItemPtr:
   def __init__(self, obj, key):
  self.obj = obj
  self.key = key
   def ___setvalue___(self, value):
  self.obj[self.key] = value
   def ___getvalue___(self)
  return self.obj[self.key]

@(foo[bar]) returns ItemPtr(foo, bar)
@baz where bar is a global variable returns ItemPtr(globals(), 'baz')
@quux where quux is local returns a cell object (any local that is used
in such an expression becomes a cell variable as with any local that is
used in a closure), and the cell type shall have these methods added to
it.
@(foo.bar) returns AttrPtr(foo, 'bar') where AttrPtr is a similarly
defined type.

We could even support a kind of "pointer arithmetic" for ItemPtr to
list-like containers:

def __add__(self, offset):
return ItemPtr(self.obj, self.key + offset)
def __getitem__(self, offset):
return self.obj[self.key + offset]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

[Steven D'Aprano]

On Tue, 7 Jun 2016 10:32 pm, Antoon Pardon wrote:

> That people often use the shortcut "x is 999" doesn't make the statement
> wrong that variables are essentially references in Python.

No, I'm sorry, you're wrong, variables are essentially arrays of bits in
Python.



-- 
Steven

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

Re: Recommendation for GUI lib?

[Dietmar Schwertberger]

On 07.06.2016 09:22, Nick Sarbicki wrote:
I think that's a bit of an unfair statement. Sure conversion can be a 
bit of a pain and there is some setup for getting the classes working. 
But that is generally a small static piece of code you can find all 
over the net, which is then usable for most projects.
The small static piece will just import the GUI. Still then, if the GUI 
actually serves a purpose, you need to address all the controls and 
events yourself. At that point, you will soon find that you need to know 
as much as if you created the GUI in code.
Anway, for GUI development I recommend using a good debugger like that 
of Wing IDE. Just set a breakpoint or wait for an exception and then 
write the GUI in the debugger utilizing the introspection features.


But for me, once past the understanding, coding GUIs by hand is about 
as dull as it gets. Qt creator definitely makes the work go faster.
For starting into wxPython I did use wxDesigner. For the first steps 
into Qt (PySide at that time), I did use Qt Creator.
But beyond the the first steps and getting used to sizers, currently 
you're better off with coding the GUI, probably utilizing your previous 
code for copy&paste (or with wxPython, copy&paste from the demo).
Still, I would like to see a decent GUI builder with RAD features 
enabling also newcomers to write GUI programs.
Most GUI programs just need a form to enter something and a start or 
save button to trigger the action. The steep learning curve for Python 
GUIs is holding back many people from using Python for e.g. measurement 
automatization. It's almost impossible to 'sell' a console-only 
environment in corporate environments. And the process that is required 
to implement a GUI using Qt Designer is not much of an improvement either.
IMHO, as of today the only GUI builder that could be developed into this 
RAD direction is wxGlade. For Qt Designer it would be possible to bridge 
the gap by adapting an IDE, though (like Eric tries).




Regards,

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

conception heritage or interface to multiprotocol read/write

[Ni Va]

Hi,


In industrial project many protocols are often used for read/write goal at 
arrival. 

I would like to implement the better designed conception to enable read/write 
feature my main program.

Example be abale to read/write on opc, s7 or others protocoles.

If you have advices about this.
Thank you
Best Regards
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Recommendation for GUI lib?

[Roland Koebler via Python-list]

Hi,

the two "big" GUI toolkits on Linux are GTK+ and Qt.

Both are free, have Python bindings and a graphical GUI designer, and both
have ports for Windows and Mac OS X. Qt does have a better cross-platform-
support and supports more platforms, but GTK+3 also works for Linux, Mac
OS X and Windows.

I myself prefer and recommend GTK+ (http://www.gtk.org), with Glade
(https://glade.gnome.org/) as GUI-builder. I'm using it with Python
for many years now. The major downside is, that the GTK+-documentation
is mainly written for C, but there are many tutorials about Python + GTK+
out there, e.g. https://python-gtk-3-tutorial.readthedocs.io/.
But be sure to use GTK+3 and the PyGObject/PyGI-binding and not the old
PyGTK-binding (and ideally Python 3).
You may also have a look at https://wiki.gnome.org/Projects/GTK+/OSX/Python

You can also try Qt (http://qt.io), and one of its Python-bindings.
But I was never happy with Qt and think some GUI-concepts of GTK+ are much
better than the ones of Qt, and I like Glade much more than the Qt designer.


best regards
Roland
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[Lawrence D’Oliveiro]

On Wednesday, June 8, 2016 at 12:28:02 AM UTC+12, Dan Sommers wrote:
> I notice plenty of break statements scattered throughout your loop
> bodies.  Mixing the loop's exit conditions in with the logic is equally
> unstructured.

Is this the old “structured-programming-is-mathematically-equivalent-to-gotos” 
red herring again?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[Lawrence D’Oliveiro]

On Tuesday, June 7, 2016 at 11:53:46 PM UTC+12, Ian wrote:
> On Tue, Jun 7, 2016 at 1:52 AM, Lawrence D’Oliveiro wrote:

>> Wow, that’s only twice the length of the code you’re replacing. Well done.
> 
> Huh? The example that you posted was 17 lines, excluding comments. My
> replacement code is 17 lines, excluding comments. Where are you
> getting "twice the length" from?

Maybe not twice. But your code for dealing with the include stack was 16 lines, 
as opposed to 13 in mine.

While elsewhere, you were criticizing my code for already being so terribly 
large...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[Lawrence D’Oliveiro]

On Tuesday, June 7, 2016 at 8:00:31 PM UTC+12, Marko Rauhamaa wrote:
> I understand you are hurt when your code is criticized bluntly. However,
> you *did* stick your head out.

Don’t worry, I am not the thin-skinned type.

> I, too, insist that every function/method must be visible at once in the
> editor window.

From subprocess.py in the Python 3.5 distribution:

if _mswindows:
#
# Windows methods
#
def _get_handles(self, stdin, stdout, stderr):
"""Construct and return tuple with IO objects:
p2cread, p2cwrite, c2pread, c2pwrite, errread, errwrite
"""
if stdin is None and stdout is None and stderr is None:
return (-1, -1, -1, -1, -1, -1)

p2cread, p2cwrite = -1, -1
c2pread, c2pwrite = -1, -1
errread, errwrite = -1, -1

if stdin is None:
p2cread = _winapi.GetStdHandle(_winapi.STD_INPUT_HANDLE)
if p2cread is None:
p2cread, _ = _winapi.CreatePipe(None, 0)
p2cread = Handle(p2cread)
_winapi.CloseHandle(_)
elif stdin == PIPE:
p2cread, p2cwrite = _winapi.CreatePipe(None, 0)
p2cread, p2cwrite = Handle(p2cread), Handle(p2cwrite)
elif stdin == DEVNULL:
p2cread = msvcrt.get_osfhandle(self._get_devnull())
elif isinstance(stdin, int):
p2cread = msvcrt.get_osfhandle(stdin)
else:
# Assuming file-like object
p2cread = msvcrt.get_osfhandle(stdin.fileno())
p2cread = self._make_inheritable(p2cread)

if stdout is None:
c2pwrite = _winapi.GetStdHandle(_winapi.STD_OUTPUT_HANDLE)
if c2pwrite is None:
_, c2pwrite = _winapi.CreatePipe(None, 0)
c2pwrite = Handle(c2pwrite)
_winapi.CloseHandle(_)
elif stdout == PIPE:
c2pread, c2pwrite = _winapi.CreatePipe(None, 0)
c2pread, c2pwrite = Handle(c2pread), Handle(c2pwrite)
elif stdout == DEVNULL:
c2pwrite = msvcrt.get_osfhandle(self._get_devnull())
elif isinstance(stdout, int):
c2pwrite = msvcrt.get_osfhandle(stdout)
else:
# Assuming file-like object
c2pwrite = msvcrt.get_osfhandle(stdout.fileno())
c2pwrite = self._make_inheritable(c2pwrite)

if stderr is None:
errwrite = _winapi.GetStdHandle(_winapi.STD_ERROR_HANDLE)
if errwrite is None:
_, errwrite = _winapi.CreatePipe(None, 0)
errwrite = Handle(errwrite)
_winapi.CloseHandle(_)
elif stderr == PIPE:
errread, errwrite = _winapi.CreatePipe(None, 0)
errread, errwrite = Handle(errread), Handle(errwrite)
elif stderr == STDOUT:
errwrite = c2pwrite
elif stderr == DEVNULL:
errwrite = msvcrt.get_osfhandle(self._get_devnull())
elif isinstance(stderr, int):
errwrite = msvcrt.get_osfhandle(stderr)
else:
# Assuming file-like object
errwrite = msvcrt.get_osfhandle(stderr.fileno())
errwrite = self._make_inheritable(errwrite)

return (p2cread, p2cwrite,
c2pread, c2pwrite,
errread, errwrite)

Is that “visible at once” in your editor window?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[Marko Rauhamaa]

Lawrence D’Oliveiro :
> While elsewhere, you were criticizing my code for already being so
> terribly large...

Code can be large, only no function should be longer than ~70 lines or
wider than 79 columns. If your function grows above that limit, you
should refactor it and break it into multiple subroutines.


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

Re: for / while else doesn't make sense

[Lawrence D’Oliveiro]

On Wednesday, June 8, 2016 at 10:07:05 AM UTC+12, Marko Rauhamaa wrote:
> Lawrence D’Oliveiro:

>> While elsewhere, you were criticizing my code for already being so
>> terribly large...
> 
> Code can be large, only no function should be longer than ~70 lines or
> wider than 79 columns. If your function grows above that limit, you
> should refactor it and break it into multiple subroutines.

It already had lots of subfunctions, in case you hadn’t noticed...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Recommendation for GUI lib?

[Michael Torrie]

Accidentally didn't reply to the list...

On 06/07/2016 03:45 PM, Roland Koebler via Python-list wrote:
> You can also try Qt (http://qt.io), and one of its Python-bindings.
> But I was never happy with Qt and think some GUI-concepts of GTK+ are much
> better than the ones of Qt, and I like Glade much more than the Qt
designer.

Yes there are some concepts in regards to GUI layout that are different
from Qt and GTK.  Particularly how widgets are packed into boxes and how
they resize.  At first I didn't like the Qt model with its "spring"
spacer thing.  But I got used to it and found it was actually more
flexible than GTK's packing method.  Just a slightly different way of
thinking about layout is all.

I think the GTK bindings are a bit more comfortable in Python that Qt's
are.  Often times Qt apps turn out more like C++ apps transliterated
into Python.  They don't quite feel as "pythonic" as the GTK+ apps.

Both are excellent toolkits.  I think Qt is more complete and has more
batteries included, particularly on the other platforms.  For example,
vector graphics. GTK+ defers that to Cairo.

All that said, I still prefer GTK also.


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

Re: for / while else doesn't make sense

[Ian Kelly]

On Tue, Jun 7, 2016 at 3:58 PM, Lawrence D’Oliveiro
 wrote:
> On Tuesday, June 7, 2016 at 11:53:46 PM UTC+12, Ian wrote:
>> On Tue, Jun 7, 2016 at 1:52 AM, Lawrence D’Oliveiro wrote:
>
>>> Wow, that’s only twice the length of the code you’re replacing. Well done.
>>
>> Huh? The example that you posted was 17 lines, excluding comments. My
>> replacement code is 17 lines, excluding comments. Where are you
>> getting "twice the length" from?
>
> Maybe not twice. But your code for dealing with the include stack was 16 
> lines, as opposed to 13 in mine.

Well, I don't know how you're counting that. All the code for dealing
with the include stack is in the generate_lines function, which is 10
lines long. The remaining code is then simpler for not having to deal
with it. In the original version, I can't identify which lines are
"dealing with the include stack" because they're so intertwined. For
example, all the sporadic code checking for line == None or line !=
None only need to exist because of the include stack.
-- 
https://mail.python.org/mailman/listinfo/python-list

Possible PEP - two dimensional arrays?

[Harrison Chudleigh]

I was programming a computer game and found that while 1D arrays can be
created using the module array, there is no module for two-dimensional
arrays, unlike languages like C. Currently, the closest thing Python has to
a 2D array is a dictionary containing lists.

I propose that a module , 2DArray, be added to the standard library. This
module will include:
Assignment and retrieval on items on a two-dimensional, finite rectangular
grid. Types are integer, float, character and string.
Resizing the grid - parameters are old size and new size. Any new elements
are initialized with a value of 0 for int, 0.0 for float and ' ' for string
and character arrays.
Removing elements. The parameter is the location. After removal, the value
returned is 0 for int, 0.0 for float and ' ' for string and character
arrays.
A function, pop(), which removes elements from the grid and then returns
them.

Is this idea PEPable?
***
This message is intended for the addressee named and may contain privileged 
information or confidential information or both. If you are not the intended 
recipient please delete it and notify the sender.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Possible PEP - two dimensional arrays?

[Paul Rubin]

Harrison Chudleigh  writes:
> Currently, the closest thing Python has to a 2D array is a dictionary
> containing lists.

Tuples work fine:
  d = {}
  d[2,3] = 5  # etc...

> Is this idea PEPable?

I don't think it would get any traction.  If you're doing something
numerical that needs 2d arrays, numpy supports them.  Actually, looking
at your application, numpy might be what you want.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[Ned Batchelder]

On Tuesday, June 7, 2016 at 6:07:23 PM UTC-4, Lawrence D’Oliveiro wrote:
> On Tuesday, June 7, 2016 at 8:00:31 PM UTC+12, Marko Rauhamaa wrote:
> > I understand you are hurt when your code is criticized bluntly. However,
> > you *did* stick your head out.
> 
> Don’t worry, I am not the thin-skinned type.
> 
> > I, too, insist that every function/method must be visible at once in the
> > editor window.
> 
> From subprocess.py in the Python 3.5 distribution:
> 
> if _mswindows:
> #
> # Windows methods
> #
> def _get_handles(self, stdin, stdout, stderr):
> """Construct and return tuple with IO objects:
> 
> ... 8< snip 8< ...
> 
> errwrite = self._make_inheritable(errwrite)
> 
> return (p2cread, p2cwrite,
> c2pread, c2pwrite,
> errread, errwrite)
> 
> Is that “visible at once” in your editor window?

Lawrence, Marko didn't write that function. Marko didn't claim that all
functions fit in a window, just that he wants his to.

Lawrence writes code in an unusual style, not a style I would write in,
but we aren't going to be able to change his mind.  It seems like this 
discussion has gone beyond the productive stage.  We aren't going to 
come to consensus on coding style.

--Ned.

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

Re: Possible PEP - two dimensional arrays?

[Ned Batchelder]

On Tuesday, June 7, 2016 at 8:19:33 PM UTC-4, Harrison Chudleigh wrote:
> I was programming a computer game and found that while 1D arrays can be
> created using the module array, there is no module for two-dimensional
> arrays, unlike languages like C. Currently, the closest thing Python has to
> a 2D array is a dictionary containing lists.
> 
> I propose that a module , 2DArray, be added to the standard library. This
> module will include:
> Assignment and retrieval on items on a two-dimensional, finite rectangular
> grid. Types are integer, float, character and string.
> Resizing the grid - parameters are old size and new size. Any new elements
> are initialized with a value of 0 for int, 0.0 for float and ' ' for string
> and character arrays.
> Removing elements. The parameter is the location. After removal, the value
> returned is 0 for int, 0.0 for float and ' ' for string and character
> arrays.
> A function, pop(), which removes elements from the grid and then returns
> them.
> 
> Is this idea PEPable?

People who need arrays like this generally use numpy, which has good support
for N-dimensional arrays and all of the operations you'd like on them.

I don't think Python would consider adding something like this to the 
standard library since numpy is available.

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

Re: Possible PEP - two dimensional arrays?

[Rob Gaddi]

Harrison Chudleigh wrote:

> I was programming a computer game and found that while 1D arrays can be
> created using the module array, there is no module for two-dimensional
> arrays, unlike languages like C. Currently, the closest thing Python has to
> a 2D array is a dictionary containing lists.
>
> I propose that a module , 2DArray, be added to the standard library. This
> module will include:
> Assignment and retrieval on items on a two-dimensional, finite rectangular
> grid. Types are integer, float, character and string.
> Resizing the grid - parameters are old size and new size. Any new elements
> are initialized with a value of 0 for int, 0.0 for float and ' ' for string
> and character arrays.
> Removing elements. The parameter is the location. After removal, the value
> returned is 0 for int, 0.0 for float and ' ' for string and character
> arrays.
> A function, pop(), which removes elements from the grid and then returns
> them.
>
> Is this idea PEPable?
> ***
> This message is intended for the addressee named and may contain privileged 
> information or confidential information or both. If you are not the intended 
> recipient please delete it and notify the sender.

You're looking for numpy.

-- 
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: for / while else doesn't make sense

[Lawrence D’Oliveiro]

On Wednesday, June 8, 2016 at 12:32:01 PM UTC+12, Ned Batchelder wrote:
> On Tuesday, June 7, 2016 at 6:07:23 PM UTC-4, Lawrence D’Oliveiro wrote:
> > On Tuesday, June 7, 2016 at 8:00:31 PM UTC+12, Marko Rauhamaa wrote:
> > > I understand you are hurt when your code is criticized bluntly. However,
> > > you *did* stick your head out.
> > 
> > Don’t worry, I am not the thin-skinned type.
> > 
> > > I, too, insist that every function/method must be visible at once in the
> > > editor window.
> > 
> > From subprocess.py in the Python 3.5 distribution:
> > 
> > if _mswindows:
> > #
> > # Windows methods
> > #
> > def _get_handles(self, stdin, stdout, stderr):
> > """Construct and return tuple with IO objects:
> > 
> > ... 8< snip 8< ...
> > 
> > errwrite = self._make_inheritable(errwrite)
> > 
> > return (p2cread, p2cwrite,
> > c2pread, c2pwrite,
> > errread, errwrite)
> > 
> > Is that “visible at once” in your editor window?
> 
> Lawrence, Marko didn't write that function. Marko didn't claim that all
> functions fit in a window, just that he wants his to.

Given that he was (presumably) commenting on my code, naturally I understood 
his statement to apply to code that he had not written.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[Lawrence D’Oliveiro]

On Wednesday, June 8, 2016 at 12:32:01 PM UTC+12, Ned Batchelder wrote:

> Lawrence writes code in an unusual style...

“Unusual” I can deal with. But when some people react with outrage, then it 
becomes clear they view my code as a personal attack.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: for / while else doesn't make sense

[Ned Batchelder]

On Tuesday, June 7, 2016 at 9:29:59 PM UTC-4, Lawrence D’Oliveiro wrote:
> On Wednesday, June 8, 2016 at 12:32:01 PM UTC+12, Ned Batchelder wrote:
> 
> > Lawrence writes code in an unusual style...
> 
> “Unusual” I can deal with. But when some people react with outrage, then it 
> becomes clear they view my code as a personal attack.

This is why we should drop it.  It doesn't seem like people are trying to
understand each other, just score points and prove each other wrong. That
isn't going to lead anywhere good.

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

pandas.datetime addition: What's wrong?

[Paulo da Silva]

Hi all!

What's wrong with this?

import pandas as pd
x=pd.to_datetime("20160501")

x+pd.DateOffset(days=1)
Timestamp('2016-05-02 00:00:00', tz=None)

x.__add__(pd.DateOffset(days=1))
NotImplemented


More generally I have a class derived from pandas.datetime and I want to
implement its own __add__ that at a given point call super __add__.

For example:

class C(pandas.datetime):
...
def __add__(self,n):
...
r=super(C,self).__add__(pd.DateOffset(days=n))
...
BTW, in the last line is it needed and how to "cast" self to
pandas.datetime?

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

Creating A Pythonic API Binding

[Lawrence D’Oliveiro]

The wrong way:

ldo@theon:~> python2
Python 2.7.11+ (default, May  9 2016, 15:54:33)
[GCC 5.3.1 20160429] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pymtp
>>> mtp = pymtp.MTP()
>>> mtp.connect()
Device 0 (VID=04e8 and PID=6860) is a blah blah blah
>>> topdirs = dict((t.name, t) for t in mtp.get_parent_folders())
>>> alldirs = mtp.get_folder_list()
>>> photos_root = topdirs["DCIM"]
>>> photos_dir = list(f for f in alldirs.values() if f.name == "Camera" and 
f.parent_id == photos_root.folder_id)[0]
>>> print(list(f for f in mtp.get_filelisting() if f.parent_id == 
photos_dir.folder_id))
[IMG_20150502_141333.jpg (5184), IMG_20150502_141336.jpg (5185), etc]
>>> mtp.disconnect()
>>>^D

The right way :

ldo@theon:~> python3
Python 3.5.1+ (default, May  9 2016, 11:00:17)
[GCC 5.3.1 20160429] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import mtpy
>>> dev = mtpy.get_raw_devices()[0].open()
Device 0 (VID=04e8 and PID=6860) is a blah blah blah
>>> p = dev.get_descendant_by_path("/DCIM/Camera")
>>> p.get_children()
[, , etc]
>>> dev.close()
>>>^D
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pandas.datetime addition: What's wrong?

[MRAB]

On 2016-06-08 03:09, Paulo da Silva wrote:

Hi all!

What's wrong with this?

import pandas as pd
x=pd.to_datetime("20160501")

x+pd.DateOffset(days=1)
Timestamp('2016-05-02 00:00:00', tz=None)

x.__add__(pd.DateOffset(days=1))
NotImplemented


More generally I have a class derived from pandas.datetime and I want to
implement its own __add__ that at a given point call super __add__.

For example:

class C(pandas.datetime):
...
def __add__(self,n):
...
r=super(C,self).__add__(pd.DateOffset(days=n))
...
BTW, in the last line is it needed and how to "cast" self to
pandas.datetime?

Thanks for any help

When you have x+y, it tries x.__add__(y). If that fails, it then tries 
y.__radd__(x).


Does that mean that the calculation above is actually implemented by the 
DateOffset class?


Does pd.to_datetime return a datetime instance?

I suspect what's happening is that it's returning NotImplemented because 
you're adding a DateOffset instance (from the pandas module) to a 
datetime instance returned by pd.to_datetime (from the datetime module), 
and the datetime class doesn't know about the DateOffset class. By 
calling the dunder method directly, you're not giving Python the 
opportunity to try the other dunder method.


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

Re: for / while else doesn't make sense

[Ethan Furman]

On 06/01/2016 04:39 PM, Lawrence D’Oliveiro wrote:

[multiple apparent trolls redacted]

This thread is dead.  Please stop beating it.

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

Re: pandas.datetime addition: What's wrong?

[Paulo da Silva]

Às 04:08 de 08-06-2016, MRAB escreveu:
> On 2016-06-08 03:09, Paulo da Silva wrote:
>> Hi all!
>>
...
>>
>> More generally I have a class derived from pandas.datetime and I want to
>> implement its own __add__ that at a given point call super __add__.
>>
>> For example:
>>
>> class C(pandas.datetime):
>> ...
>> def __add__(self,n):
>> ...
>> r=super(C,self).__add__(pd.DateOffset(days=n))
>> ...
>> BTW, in the last line is it needed and how to "cast" self to
>> pandas.datetime?
>>
...

> When you have x+y, it tries x.__add__(y). If that fails, it then tries
> y.__radd__(x).
That's it!
> 
> Does that mean that the calculation above is actually implemented by the
> DateOffset class?
It seems so. Using __radd__ it works.
> 
> Does pd.to_datetime return a datetime instance?
Yes.
> 
I still have the problem of self being C (not pandas.datetime).
I tried self.__class__=pandas.datetime but it says
something like "__class__ assignment: only for heap types"
I don't know what this means.

Using a new object op=pandas.datetime(self.year,self.month,self.day)
works but it's too heavy :-)

Thank you very much.


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

Re: for / while else doesn't make sense

[Marko Rauhamaa]

Lawrence D’Oliveiro :

> On Tuesday, June 7, 2016 at 8:00:31 PM UTC+12, Marko Rauhamaa wrote:
>> I, too, insist that every function/method must be visible at once in the
>> editor window.
>
> From subprocess.py in the Python 3.5 distribution:
> [...]
> Is that “visible at once” in your editor window?

At home, no; at work, yes.

Anyway, I didn't write that piece of code so my insisting doesn't affect
it one way or another.


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

Re: for / while else doesn't make sense

[Marko Rauhamaa]

Lawrence D’Oliveiro :

> On Wednesday, June 8, 2016 at 10:07:05 AM UTC+12, Marko Rauhamaa wrote:
>> Lawrence D’Oliveiro:
>
>>> While elsewhere, you were criticizing my code for already being so
>>> terribly large...
>> 
>> Code can be large, only no function should be longer than ~70 lines
>> or wider than 79 columns. If your function grows above that limit,
>> you should refactor it and break it into multiple subroutines.
>
> It already had lots of subfunctions, in case you hadn’t noticed...

I didn't take a look at your code. Someone mentioned you had a 500-line
function.


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

Re: I'm wrong or Will we fix the ducks limp?

[Gregory Ewing]

Random832 wrote:

Er, how would that make them not first class?


They wouldn't be as transparent as references in C++,
which you just assign to like any other variable.

That works because C++ makes a distinction between
initialisation and assignment. It's not so easy to
separate those in Python.


"Assign to the variable object that is in this
variable" would be a distinct operation from "Assign to this variable",
just like "add one to this value" or "call this function" etc.


That would be like pointers in C that you have
to explicitly dereference. I'm not sure whether
C could be described as having "first class
variables", though.

If transparency is not required, you can easily
create wrapper objects in Python that refer
to an attribute or element of an object.

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