Hello

[rubengoodson3--- via Python-list]

I am having trouble installing the Python software.






Sent from Windows Mail
-- 
https://mail.python.org/mailman/listinfo/python-list

a clarification on the "global" statement sought

[Charles T. Smith]

When might a "global" statement be used in the outermost level of a module?

(whereby, I assume a module is equivalent to a python file, correct?)

TIA for any thoughts.

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

Re: Hello

[Mark Lawrence]

On 11/03/2016 03:28, rubengoodson3--- via Python-list wrote:

I am having trouble installing the Python software.
Sent from Windows Mail



This type of question has been asked and answered repeatedly over the 
last few months so I suggest that you search the archives for your 
precise problem.


--
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: a clarification on the "global" statement sought

[Chris Angelico]

On Fri, Mar 11, 2016 at 7:13 PM, Charles T. Smith
 wrote:
> When might a "global" statement be used in the outermost level of a module?
>
> (whereby, I assume a module is equivalent to a python file, correct?)
>

Usefully? Never.

Simple question - simple answer :)

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

Re: a clarification on the "global" statement sought

[Mark Lawrence]

On 11/03/2016 08:13, Charles T. Smith wrote:

When might a "global" statement be used in the outermost level of a module?


Never. Hopefully this 
http://www.python-course.eu/python3_global_vs_local_variables.php can 
explain it better than I can :)




(whereby, I assume a module is equivalent to a python file, correct?)


Correct.



TIA for any thoughts.

cts



--
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: Other difference with Perl: Python scripts in a pipe

[Ethan Furman]

On 03/10/2016 04:26 PM, Fillmore wrote:

On 3/10/2016 7:08 PM, INADA Naoki wrote:


No.  I see it usually.

Python's zen says:


Errors should never pass silently.
Unless explicitly silenced.


When failed to write to stdout, Python should raise Exception.
You can silence explicitly when it's safe:

try:
 print(...)
except BrokenPipeError:
 os.exit(0)



I don't like it. It makes Python not so good for command-line utilities


You don't like typing two extra lines of code?

Or don't you like needing to understand what is going on so you know 
when to silence errors?


The try/except paradigm is very useful -- it's worth learning.

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

Re: a clarification on the "global" statement sought

[Charles T. Smith]

On Fri, 11 Mar 2016 19:29:20 +1100, Chris Angelico wrote:

> Usefully? Never.
> 
> Simple question - simple answer :)
> 
> ChrisA


Right, that was the expected answer as well.  I just ran into that in
legacy code, checked out the documentation and couldn't really make that
out.  So I figured I better ask here before I end up with egg on my face

:)

Thanks folks.

Actually, it would be nice if there were a -lint or -warnings flag
for such cases, a la perl or gcc.
-- 
https://mail.python.org/mailman/listinfo/python-list

Remote Rsponse Socket Connection

[Joaquin Alzola]

HI Guys

I received this from a socket connection. This is the received data:

>From python function --> data = s.recv(2048)

b'\x01\x00\x00D\x00\x00\x01\x18\x00\x00\x00\x00p2E\xe1+\xe8xG\x00\x00\x01\x08@\x00\x00\x0bmmm\x00\x00\x00\x01(@\x00\x00\x16mmm.xx.com\x00\x00\x00\x00\x01\x0c@\x00\x00\x0c\x00\x00\x07\xd1'

I received a byte string with hexadecimal values and some extra junk like 
\x0bmmm (mmm). But that junk needs to be on the message.
How is the best way to decode such reply from server?

BR

Joaquin
This email is confidential and may be subject to privilege. If you are not the 
intended recipient, please do not copy or disclose its content but contact the 
sender immediately upon receipt.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to program round this poplib error?

[dieter]

c...@isbd.net writes:

> I have a (fairly simple) Python program that scans through a
> 'catchall' E-Mail address for things that *might* be for me.  It sends
> anything that could be for me to my main E-Mail and discards the rest.
>
> However I *occasionally* get an error from it as follows:-
>
> Traceback (most recent call last):
>   File "/home/chris/.mutt/bin/getCatchall.py", line 65, in 
> pop3.dele(i+1)
>   File "/usr/lib/python2.7/poplib.py", line 240, in dele
> return self._shortcmd('DELE %s' % which)
>   File "/usr/lib/python2.7/poplib.py", line 160, in _shortcmd
> return self._getresp()
>   File "/usr/lib/python2.7/poplib.py", line 132, in _getresp
> resp, o = self._getline()
>   File "/usr/lib/python2.7/poplib.py", line 377, in _getline
> raise error_proto('line too long')
> poplib.error_proto: line too long
>
>
> Does anyone have any idea how I can program around this somehow?

This is bug "https://bugs.python.org/issue23906";.

Following a recommendation from "Laura Creighton", I work around it
by

import poplib; poplib._MAXLINE=5


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

Re: a clarification on the "global" statement sought

[Charles T. Smith]

On Fri, 11 Mar 2016 08:31:22 +, Mark Lawrence wrote:

> Never. Hopefully this
> http://www.python-course.eu/python3_global_vs_local_variables.php can
> explain it better than I can :)


The article is good, I'm glad to have confirmed what I have so empirical
stumbled over.
... Irrespective of the "python-speak" (or to be fair,
evangelical-speak):

  "Python deals with variables the other way around.
   They are local, if not otherwise declared.
   ...
def f(): 
print(s) 
s = "I love Paris in the summer!"
f()
...
As there is no local variable s, i.e. no assignment to s, the value
from the ***global*** variable s will be used."

Indeed "maverick": that a variable can be an undefined global
and then only appears as such when assigned to, has caused me
no end of grief.

Nevertheless, python is still a fun language to program in.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: context managers inline?

[Jussi Piitulainen]

Paul Rubin writes:

> Jussi Piitulainen writes:
>> return ModeIO(f.read())
>
> These suggestions involving f.read() assume the file contents are small
> enough to reasonably slurp into memory.  That's unlike the original
> where "load" receives a stream and might process it piecewise.

If you strike that word "reasonably", then yes, of course they do. A
_reasonable_ answer to the original question may well be "no", even
though it's not strictly true (because load can be written to close the
file, because open can be replaced with something that closes the file,
or registers the file with some mechanism that closes the file at a
convenient time, assuming the programmer ensures that that time
eventually comes, because one can trust the memory management system to
close the file, assuming the unreachable file object is eventually
collected).

I think the following was also effectively given by someone already. It
would work, _assuming_ that the user is happy to use higher order
functions and especially _lambda_ (or restrict themself to always use
unary functions in place of their load, which to me is the most bizarre
suggestion so far). My impression of the Python community is that there
is some resistance to higher order functions and _especially_ to lambda.

def load(o, length = 1): return [ line[:length] for line in o ]

def closing(p, o):
with o as f:
return p(f)

x = closing(load, open('Chipsta/Demo.org', mode = 'rb'))

y = closing(load, open('Chipsta/Demo.org', encoding = 'UTF-8'))

print(x)
print(y)

x = closing(lambda o: load(o, 2), open('Chipsta/Demo.org', mode = 'rb'))

y = closing(lambda o: load(o, 2), open('Chipsta/Demo.org', encoding = 'UTF-8'))

print(x)
print(y)

A problem with _every_ solution is that they cannot be idiomatic Python.
The idiomatic Python thing is to rearrange the code as a with-statement.

I think. (I hedge.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: a clarification on the "global" statement sought

[eryk sun]

On Fri, Mar 11, 2016 at 2:13 AM, Charles T. Smith
 wrote:
> When might a "global" statement be used in the outermost level of a module?

You wouldn't need this in a normal module, because locals and globals
are the same. It may be useful if you're using exec with separate
locals and globals, and need to set a global. For example:

source = 'global y; x, y = 1, 2'
gvars, lvars = {}, {}
exec(source, gvars, lvars)

>>> lvars
{'x': 1}
>>> gvars['y']
2

Probably you'll never need this.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: a clarification on the "global" statement sought

[Peter Otten]

Charles T. Smith wrote:

> On Fri, 11 Mar 2016 19:29:20 +1100, Chris Angelico wrote:
> 
>> Usefully? Never.
>> 
>> Simple question - simple answer :)
>> 
>> ChrisA
> 
> 
> Right, that was the expected answer as well.  I just ran into that in
> legacy code, checked out the documentation and couldn't really make that
> out.  So I figured I better ask here before I end up with egg on my face
> 
> :)
> 
> Thanks folks.
> 
> Actually, it would be nice if there were a -lint or -warnings flag
> for such cases, a la perl or gcc.

There is an external tool called pylint that among other things detects 
superfluous global statements.

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

Re: Encapsulation in Python

[dieter]

Ben Mezger  writes:

> I've been studying Object Oriented Theory using Java. Theoretically, all
> attributes should be private, meaning no one except the methods itself
> can access the attribute;
>
> public class Foo {
> private int bar;
> ...
>
> Normally in Java, we would write getters and setters to set/get the
> attribute bar. However, in Python, we normally create a class like so;
>
> class Foo(object):
> bar = 0
> ...
>
> And we usually don't write any getters/setters (though they exist in
> Python, I have not seen much projects making use of it).

If you expose publicly both a "setter" and a "getter" what is the gain
not to make the attribute public in the first case (other than
cluttering up your code).

I very much like the "Eiffel" view that there should be no
distinction between an attribute access and the call of a zero
parameter method. Thus, there are no "getter"s at all.
Unlike "Python", "Eiffel" is very interested in encapsulation:
thus attributes can be private, limited to derived classes or public --
and they can be readonly.

"Python" is much less interested in encapsulation - and more in
the ability to quickly get a solution to a practical problem.


> We can easily encapsulate (data hiding) Foo's class using the '_'
> (underscore) when creating a new attribute, however, this would require
> all attributes to have a underscore.

And it is only a hint towards users of the class. Nothing forces
a piece of code to use it as public.

> According to this answer [1], it's acceptable to to expose your
> attribute directly (Foo.bar = 0), so I wonder where the encapsulation
> happens in Python? If I can access the attribute whenever I want (with
> the except of using a underscore), what's the best way to encapsulate a
> class in Python?

If you are really interested to enforce Java encapsulation policies
(access to attributes via "getter/setter" only), you will need
to use your own "metaclass".

The "metaclass" has a similar relation to a class as a class to
an instance: i.e. it constructs a class. During the class construction,
your "metaclass" could automatically define "getter/setter" methods
for declared class attributes and hide the real attributes (maybe
by prefixing with "__").
Of course, class level (non-method) attributes are rare; most
attributes of Python instances are not defined at the class level
but directly at the instance level - and the metaclass would
need to define "__setattr__" and "__getattribute__" to control access
to them.

However, I think you should not use Python in cases where you
need strong encapsulation.

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

Re: a clarification on the "global" statement sought

[Chris Angelico]

On Fri, Mar 11, 2016 at 8:09 PM, Charles T. Smith
 wrote:
>   "Python deals with variables the other way around.
>They are local, if not otherwise declared.
>...
> def f():
> print(s)
> s = "I love Paris in the summer!"
> f()
> ...
> As there is no local variable s, i.e. no assignment to s, the value
> from the ***global*** variable s will be used."
>
> Indeed "maverick": that a variable can be an undefined global
> and then only appears as such when assigned to, has caused me
> no end of grief.

Looking purely at the function definition, you can see with 100%
certainty that it references two non-local names: "print" and "s".
Neither is assigned to within the function, so both are looked up
externally. At run time, s is resolved as a module-level name; print
is not, so Python looks further, to the builtins. Had s not been
assigned to, it would still be a global name in the function, but it
would fail to be found in either the module namespace or the builtins,
and would result in NameError. But either way, it's a global name,
whether it's assigned to or not.

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

Re: Encapsulation in Python

[Steven D'Aprano]

On Fri, 11 Mar 2016 12:41 am, Ben Mezger wrote:

> Hi all,
> 
> I've been studying Object Oriented Theory using Java. Theoretically, all
> attributes should be private, meaning no one except the methods itself
> can access the attribute;

(Note: in the following, when I say "encapsulation", I am actually referring
to *data hiding*.)

That's one theory. Another theory is: no they shouldn't, all attributes
should be public. That most accurately models actual physical objects and
maximises the usefulness of the attribute.

People over-use private, and if you google, you will find many people
asking "how can I access private variables and methods?". You will also
learn that encapsulation is the enemy of test-drive development:

https://jasonmbaker.wordpress.com/2009/01/08/enemies-of-test-driven-development-part-i-encapsulation/

and also of good user-interfaces:

https://ayende.com/blog/4375/encapsulation-is-the-enemy-of-the-user-interface

Some might say that encapsulation is a waste of time:

http://c2.com/cgi/wiki?EncapsulationIsaWasteOfTime

See also:

http://c2.com/cgi/wiki?MethodsShouldBePublic
http://c2.com/cgi/wiki?ForgetAboutWritingAccessors


Python offers a middle ground: where encapsulation is important for safety,
use it, otherwise rely on trust and a gentleman's agreement. We're all
adults here: if you use my internals, that's your choice, and you can live
with the consequences.

In practice this means that internal details of classes written in C are
completely hidden from Python code unless explicitly made public. Why?
Because if the caller messes with the internal data of a C class, they can
cause a segmentation fault, which can execute arbitrary code. This is a
serious problem, and Python has a philosophy of Absolutely No Seg Faults.
It should be impossible to cause the Python interpreter to seg fault or
dump core (except via ctypes, which is special). That means that classes
written in C are hide their internals.

But what about Python classes? You can't cause a seg fault in Python code.
So Python's philosophy is:

- trying to *enforce* private data is a waste of time, people will find a
way around it, even if it is a horrible nasty hack;

- so instead, rely on trust: we mark "private" attributes with a leading
underscore, and trust that users won't abuse them;

- if they do, the consequences are on their head, not ours: you have no
responsibility to users who misuse your private attributes.

Furthermore, are you *sure* that you need private attributes? That will, of
course, depend on the size of the project you are working on. If it is a
small class in a small program, then it is probably a waste of time and
effort: You Ain't Going To Need It.

Python gives you five levels of enforcement of encapsulation:

1. None what so ever. YAGNI, so just use a regular attribute and 
   don't over-engineer your simple class.

2. Trust the user to obey the naming convention: name the 
   attribute with a leading underscore to make it private by
   convention.

3. If you need to offer a public interface which differs from 
   your internal implementation, you can use properties or 
   custom-made descriptors to implement getters and setters 
   which look like ordinary attribute access. (This often 
   relies on #2 as well.)

4. The encapsulation offered by closures is even harder to 
   break, but it applies to functions, not classes.

5. For the strongest level of encapsulation, move your code
   into a C extension class.



For most users, 1 through 3 is more than enough.



> public class Foo {
> private int bar;
> ...
> 
> Normally in Java, we would write getters and setters to set/get the
> attribute bar. However, in Python, we normally create a class like so;
> 
> class Foo(object):
> bar = 0
> ...

No, normally we wouldn't. The above makes bar shared by all instances.
Normally, if you want each instance to get their own value of bar, you
would assign it in the constructor/initialiser:

class Foo(object):
def __init__(self):
self.bar = 0


For ints, this isn't much of a practical difference, but it makes a very big
difference for mutable classes like lists.


> And we usually don't write any getters/setters (though they exist in
> Python, I have not seen much projects making use of it).

Correct. YAGNI: don't use getters/setters until you have proof that you need
it, not just "well my professor tells me I should do this".

As a Java developer, you might sometimes feel that (by Java standards)
Python code is awfully slap-dash and sloppy. That's okay -- by Python
standards, Java code is awfully "bondage and discipline", strict and
pedantic.

See here:

http://dirtsimple.org/2004/12/python-is-not-java.html
http://dirtsimple.org/2004/12/java-is-not-python-either.html



> We can easily encapsulate (data hiding) Foo's class using the '_'
> (underscore) when creating a new attribute, however, this would require
> all attributes to have a underscore.

Well, if you really want t

Re: HDF5 data set, unable to read contents

[dieter]

varun...@gmail.com writes:

> I recently came across a package called matrix2latex which simplifies the 
> creation of very large tables. So, I saved my data in .mat format using the 
> '-v7.3' extension so that they can be read by python.
>
> Now, when I try to read these files, I'm having some problems in reproducing 
> the whole matrix. Whenever I try and print out an element of the array, I 
> only get 'HDF5 object reference' as the output.

"print" implicitely converts an object to a string.
As there are a huge number of potential object types, "print" itself
cannot know all the relevant details regarding string convertion for
all types -- each individual type must help (by defining
"__str__" and/or "__repr__"). If it does not help, you
get a printout as the above.

In an interactive Python session, you can use "help(...)" on
one of those "HDF5 object reference"s. This will show you the
API of the object - i.e. how to interact with the object
(such as accessing/modifying the contained information).
"vars(...)" may also help (it shows the object's (instance) attributes).

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

Re: Hello

[Steven D'Aprano]

On Fri, 11 Mar 2016 02:28 pm, rubengoods...@yahoo.com wrote:

> I am having trouble installing the Python software.

Make sure your computer is turned on. I can't tell you how many times I've
tried to install Python, and I type commands and click icons and nothing
happens. It's really frustrating when you finally realise that the reason
nothing is working is because the computer is turned off! (I thought I just
had the screen brightness turned way down.)

If that's not your problem, I'm afraid you'll have to tell us what you
tried, and what results you got. Remember that we're not watching you
install, so we have no idea of what you did. 

What version of Python did you try to install?

Where did it come from? Give us the actual URL, don't just say "from the
website". 

What OS are you running? What version? 32-bit or 64-bit?

How did you install it? What commands did you type?

What happened? Did you get an error message? What did it say? Please COPY
and PASTE any results if you can. Don't post a screen shot, because this
mailing list is also a newsgroup and attachments will be deleted. If you
absolute must use a screen shot, post it to https://imgur.com/



-- 
Steven

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

Re: Other difference with Perl: Python scripts in a pipe

[Jussi Piitulainen]

Alan Bawden writes:
> Fillmore writes:
>
>> On 3/10/2016 7:08 PM, INADA Naoki wrote:
> ...
>> I don't like it. It makes Python not so good for command-line utilities
>>
>
> You can easily restore the standard Unix command-line-friendly behavior
> by doing:
>
> import signal
> signal.signal(signal.SIGINT, signal.SIG_DFL)
> signal.signal(signal.SIGPIPE, signal.SIG_DFL)

Thank you!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: context managers inline?

[jmp]

On 03/10/2016 07:59 PM, Neal Becker wrote:

sohcahto...@gmail.com wrote:


On Thursday, March 10, 2016 at 10:33:47 AM UTC-8, Neal Becker wrote:

Is there a way to ensure resource cleanup with a construct such as:

x = load (open ('my file', 'rb))

Is there a way to ensure this file gets closed?


with open('my file', 'rb') as f:
 x = load(f)


But not in a 1-line, composable manner?



You you really want a 1 liner

with open('my file', 'rb') as f: print 'foo'; x = load(f)


jm

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

[no subject]

[Swetha Reddy]

Hi, i just downloaded the python software. when i search for it in my
downloads, a folder called python 3.5.1 ( 32 bit ) Setup is seen. But when
i try to open it, it has only three options : Modify, Repair and uninstall.
there are no other files of python in my computer except this. Where can i
get the python IDE if thats what its called, the place where you get to
type and code and create programs? please reply to thins.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: HDF5 data set, unable to read contents

[Peter Otten]

varun...@gmail.com wrote:

> Hello everyone,
> 
> I recently came across a package called matrix2latex which simplifies the
> creation of very large tables. So, I saved my data in .mat format using
> the '-v7.3' extension so that they can be read by python.
> 
> Now, when I try to read these files, I'm having some problems in
> reproducing the whole matrix. Whenever I try and print out an element of
> the array, I only get 'HDF5 object reference' as the output. This is
> basically the short code I wrote and what I basically want to do is have
> the values of the elements in the arrays and not the 'HDF5 object
> reference' thing. ex [ [ 1 2 3 4 ], [2 3 4 5 ]...]
> 
> Could you please help me with this? The link to the .mat file is as below
> 
> https://drive.google.com/file/d/0B2-j91i19ey2Nm1CbVpCQVdZc3M/view?usp=sharing
> 
> 
> import numpy as np, h5py
> from matrix2latex import matrix2latex
> 
> f = h5py.File('nominal_case_unfix.mat', 'r')
> data = f.get('nominal_case_unfix')

Did you mean _fix instead of _unfix?

> np_data = np.array(data)
> print np_data

Maybe it has something to do with the way you saved your data? When I save 
and load a matrix I don't see those object references:

$ cat h5write.py
import numpy as np
import h5py

a = np.array([[1,2,3], [4,5,6]])

f = h5py.File('save.mat', 'w')
d = f.create_dataset("foo", data=a)
f.close()
$ python h5write.py
$ cat h5read.py
import sys
import numpy as np
import h5py

filename, matrixlocation = sys.argv[1:]

f = h5py.File(filename, 'r')
d = f.get(matrixlocation)
print np.array(d)
$ python h5read.py save.mat foo
[[1 2 3]
 [4 5 6]]

However, with your data set:

$ python h5read.py nominal_case_fix.mat nominal_case_fix
[[  
[...]
]]
$


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

Re: (unknown)

[Mark Lawrence]

On 11/03/2016 11:10, Swetha Reddy wrote:

Hi, i just downloaded the python software. when i search for it in my
downloads, a folder called python 3.5.1 ( 32 bit ) Setup is seen. But when
i try to open it, it has only three options : Modify, Repair and uninstall.
there are no other files of python in my computer except this. Where can i
get the python IDE if thats what its called, the place where you get to
type and code and create programs? please reply to thins.



This has been asked and answered repeatedly over the last few months.  I 
suggest that you search the archives for the answer for your OS.


--
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: Text input with keyboard, via input methods

[Rustom Mody]

On Friday, March 11, 2016 at 10:21:35 AM UTC+5:30, Larry Hudson wrote:
> On 03/09/2016 11:54 PM, Rustom Mody wrote:
> [...]
> > In between these two extremes we have many possibilities
> > - ibus/gchar etc
> > - compose key
> > - alternate keyboard layouts
> >
> > Using all these levels judiciously seems to me a good idea...
> >
> FWIW -- in Mint Linux you can select the compose key with the following:
> 
> Preferences->Keyboard->Layouts->Options->Position of Compose Key
> 
> then check the box(s) you want.
> 
> For those unfamiliar with it, to use it you press your selected compose key 
> followed by a 
> sequence of characters (usually 2 but sometimes more).
> 
> A couple examples--
> n~ gives ñ u" gives üoo gives °  (degree sign)
> Here's a cute one:  CCCP gives ☭  (hammer & sickle)
> 
> This gives you (relatively) easy access to a large range of 'special' 
> characters.

Can be more heavily parameterized with this
https://github.com/rrthomas/pointless-xcompose
[Note the uim install]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: non printable (moving away from Perl)

[Wolfgang Maier]

One lesson for Perl regex users is that in Python many things can be 
solved without regexes. How about defining:


printable = {chr(n) for n in range(32, 127)}

then using:

if (set(my_string) - set(printable)):
break



On 11.03.2016 01:07, Fillmore wrote:


Here's another handy Perl regex which I am not sure how to translate to
Python.

I use it to avoid processing lines that contain funny chars...

if ($string =~ /[^[:print:]]/) {next OUTER;}

:)



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

Re: non printable (moving away from Perl)

[Wolfgang Maier]

On 11.03.2016 13:13, Wolfgang Maier wrote:

One lesson for Perl regex users is that in Python many things can be
solved without regexes. How about defining:

printable = {chr(n) for n in range(32, 127)}

then using:

if (set(my_string) - set(printable)):
 break



Err, I meant:

if (set(my_string) - printable):
break

of course. No need to attempt another set conversion.

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

Re:

[Igor Korot]

Hi,

On Fri, Mar 11, 2016 at 6:10 AM, Swetha Reddy  wrote:
> Hi, i just downloaded the python software. when i search for it in my
> downloads, a folder called python 3.5.1 ( 32 bit ) Setup is seen. But when
> i try to open it, it has only three options : Modify, Repair and uninstall.
> there are no other files of python in my computer except this. Where can i
> get the python IDE if thats what its called, the place where you get to
> type and code and create programs? please reply to thins.

Which OS do you use?
Where did you downloaded the package from?
Did you try to confirm you download was successful?

Thank you.

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

Re: non printable (moving away from Perl)

[Marko Rauhamaa]

Wolfgang Maier :

> On 11.03.2016 13:13, Wolfgang Maier wrote:
>> One lesson for Perl regex users is that in Python many things can be
>> solved without regexes. How about defining:
>>
>> printable = {chr(n) for n in range(32, 127)}
>>
>> then using:
>>
>> if (set(my_string) - set(printable)):
>>  break
>>
>
> Err, I meant:
>
> if (set(my_string) - printable):
> break
>
> of course. No need to attempt another set conversion.

Most non-ASCII characters are printable, or at least a good many.

Unfortunately, "printable" doesn't seem to be a Unicode category.


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

RE: Remote Rsponse Socket Connection

[Joaquin Alzola]

HI Guys

I received this from a socket connection. This is the received data:

Adding more info --> the response is a mixture of hex numbers + ascii

>From python function --> data = s.recv(2048)

b'\x01\x00\x00D\x00\x00\x01\x18\x00\x00\x00\x00p2E\xe1+\xe8xG\x00\x00\x01\x08@\x00\x00\x0bmmm\x00\x00\x00\x01(@\x00\x00\x16mmm.xx.com\x00\x00\x00\x00\x01\x0c@\x00\x00\x0c\x00\x00\x07\xd1'

How is the best way to decode such reply from server?

BR

Joaquin
This email is confidential and may be subject to privilege. If you are not the 
intended recipient, please do not copy or disclose its content but contact the 
sender immediately upon receipt.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Remote Rsponse Socket Connection

[Andrew Berg]

On 2016.03.11 07:17, Joaquin Alzola wrote:
> HI Guys
> 
> I received this from a socket connection. This is the received data:
> 
> Adding more info --> the response is a mixture of hex numbers + ascii
> 
> From python function --> data = s.recv(2048)
> 
> b'\x01\x00\x00D\x00\x00\x01\x18\x00\x00\x00\x00p2E\xe1+\xe8xG\x00\x00\x01\x08@\x00\x00\x0bmmm\x00\x00\x00\x01(@\x00\x00\x16mmm.xx.com\x00\x00\x00\x00\x01\x0c@\x00\x00\x0c\x00\x00\x07\xd1'
> 
> How is the best way to decode such reply from server?
There are generally libraries for dealing with whatever protocol you're using,
and they'll be a lot better than something you slap together yourself. If you
insist on writing your own thing, then take a look at the documentation for
that protocol (for most, this is an RFC).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Remote Rsponse Socket Connection

[Marko Rauhamaa]

Joaquin Alzola :

> I received this from a socket connection. This is the received data:
>
> Adding more info --> the response is a mixture of hex numbers + ascii
>
> [...]
>
> How is the best way to decode such reply from server?

https://docs.python.org/3/library/struct.html#examples


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

Re: non printable (moving away from Perl)

[Fillmore]

On 03/11/2016 07:13 AM, Wolfgang Maier wrote:

One lesson for Perl regex users is that in Python many things can be solved 
without regexes.
How about defining:

printable = {chr(n) for n in range(32, 127)}

then using:

if (set(my_string) - set(printable)):
 break


seems computationally heavy. I have a file with about 70k lines, of which only 20 contain 
"funny" chars.

ANy idea on how I can create a script that compares Perl speed vs. Python speed
in performing the cleaning operation?

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

RE: Remote Rsponse Socket Connection

[Joaquin Alzola]

> I received this from a socket connection. This is the received data:
>
> Adding more info --> the response is a mixture of hex numbers + ascii
>
> [...]
>
> How is the best way to decode such reply from server?

>https://docs.python.org/3/library/struct.html#examples
Thank Marko will take alook into it.

Marko
--
https://mail.python.org/mailman/listinfo/python-list
This email is confidential and may be subject to privilege. If you are not the 
intended recipient, please do not copy or disclose its content but contact the 
sender immediately upon receipt.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Encapsulation in Python

[Ian Kelly]

On Fri, Mar 11, 2016 at 2:29 AM, dieter  wrote:
> If you are really interested to enforce Java encapsulation policies
> (access to attributes via "getter/setter" only), you will need
> to use your own "metaclass".
>
> The "metaclass" has a similar relation to a class as a class to
> an instance: i.e. it constructs a class. During the class construction,
> your "metaclass" could automatically define "getter/setter" methods
> for declared class attributes and hide the real attributes (maybe
> by prefixing with "__").
> Of course, class level (non-method) attributes are rare; most
> attributes of Python instances are not defined at the class level
> but directly at the instance level - and the metaclass would
> need to define "__setattr__" and "__getattribute__" to control access
> to them.

Pythonically, one would use a property to do this. You don't need
anything so advanced as a metaclass. Using either approach though,
there is no place you can hide the real attributes where the caller
isn't capable of getting at them.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: non printable (moving away from Perl)

[Peter Otten]

Fillmore wrote:

> On 03/11/2016 07:13 AM, Wolfgang Maier wrote:
>> One lesson for Perl regex users is that in Python many things can be
>> solved without regexes. How about defining:
>>
>> printable = {chr(n) for n in range(32, 127)}
>>
>> then using:
>>
>> if (set(my_string) - set(printable)):
>>  break
> 
> seems computationally heavy. I have a file with about 70k lines, of which
> only 20 contain "funny" chars.
> 
> ANy idea on how I can create a script that compares Perl speed vs. Python
> speed in performing the cleaning operation?

Try 

for line in ...:
if has_nonprint(line):
continue
...

with the has_nonprint() function as defined below:

$ cat isprint.py
import sys
import unicodedata


class Lookup(dict):
def __missing__(self, n):
c = chr(n)
cat = unicodedata.category(c)
if cat in {'Cs', 'Cn', 'Zl', 'Cc', 'Zp'}:
self[n] = c
return c
else:
self[n] = None
return None


lookup = Lookup()
lookup[10] = None # allow newline

def has_nonprint(s):
return bool(s.translate(lookup))

$ python3 -i isprint.py
>>> has_nonprint("foo")
False
>>> has_nonprint("foo\n")
False
>>> has_nonprint("foo\t")
True
>>> has_nonprint("\0foo")
True


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

Re: Encapsulation in Python

[Ian Kelly]

On Thu, Mar 10, 2016 at 5:45 PM, Rick Johnson
 wrote:
> Many times, i would have preferred to define my module space
> across multiple files, multiple files that could share state
> without resorting to the yoga-style "import contortions",
> and/or the dreaded "circular import nightmares" that plague
> our community today.

Sounds to me like you're blaming Python for your own poor design.
Possible solutions:

1) Don't do that. If your module is too big for one file, then it's
likely poorly organized and doesn't all belong in one module anyway.

2) Clearly define which module is to be imported first. Then follow
it. When module b is imported, it should import module a. When module
a is imported, it *shouldn't* import module b until it's defined all
of its own members first. If module a depends on anything from module
b at import time, then refactor so it doesn't. This doesn't require
"contortions".

3) Just put all your damn shared state in a class. There's nothing
stopping you from spreading out your class method definitions over
multiple files if you really want to, and it solves your import issue
by allowing everything to be imported before you even begin to set up
the shared state.

>> The vast majority of getters and setters do nothing other
>> than get/set the field they belong to. They exist only to
>> allow the *possibility* of doing something else at some
>> point far in the future.
>
> But you're ignoring the most important aspect of
> getters/setters, and that is, that they expose an interface.
> An interface that must be *EXPLICITLY* created. Good
> interfaces *NEVER* happen by accident.

And you're suggesting that public attributes and properties do not
expose an interface? Rubbish.

>> That's a ton of undesirable boilerplate for little real
>> benefit.
>
> I understand the aversion to boilerplate, but most languages
> have simplified the creation of getters/setters to the point
> that your lament is unfounded. And i would argue that the
> benefits of creating rigid interfaces is the gift that
> keeps on giving.

I don't care how easy they are to *create*. Code is read much more
often than it is written, and excessive boilerplate damages
readability.

>> In Python, OO designers are able to get away with not
>> using getters and setters because we have properties. You
>> can start with an attribute, and if you later want to
>> change the means of getting and setting it, you just
>> replace it with a property. The property lets you add any
>> logic you want, and as far as the outside world is
>> concerned, it still just looks like an attribute.
>
> I used properties quite often when i first began writing
> Python code. Heck, i thought they were the best thing since
> sliced bread. But now, i have come to hate them. I never use
> them in any new code, and when i have free time, i strip
> them out of old code. When i am forced to use an interface
> that was written with properties, i find that learning the
> interface is more difficult
>
>   (1) In a dir listing, one cannot determine which symbols
>   are properties, which are attributes, and which are
>   methods. The beauty of pure OOP encapsulation, is that,
>   *EVERY* exposed symbol is a method. In pure OOP, i don't
>   have to wonder if i'm calling a function with no
>   parameters, or accessing a property, or accessing an
>   attribute, no, i'll know that every access is through a
>   method, therefore, i will append "()" when i know the
>   method takes no arguments. Consistency is very important.

How do you know the method takes no arguments from a dir listing? If
you think the method does take arguments, how do you find out what
those are from a dir listing? If you want to do actual coding with a
class, you're eventually going to have to read something other than
the dir listing, whether everything is a method or not.

>   (2) Properties and attributes encourage vague naming
>   schemes. When i read code, i find the code more
>   comprehensible when the symbols give me clues as to what
>   is going on. So if i read code like: `re.groups`,
>   befuddlement sets in. What is "groups"? A function
>   object? An attribute? "getCapturingGroupCount" would be a
>   better name (but that's semantics)

Actually, it would be wrong. Match.groups doesn't return a count.
Also, it's a method, not an attribute or property, so as an example it
sort of destroys your argument that using methods naturally results in
giving the methods good, meaningful names. These are merely separate
aspects of interface design.

>   In pure OOP,  methods
>   are the only communication meduim, so we're more likely to
>   write "getBlah" and "setBlah", and use verbs for
>   procedural names -- these naming conventions are more
>   comprehensible to the user.

Good names for methods are *descriptive* verb phrases. Good names for
attributes and properties are *descriptive* nouns or noun phrases. Do
you really believe that verbs are somehow inherently easier to
understand?

>  

Re: non printable (moving away from Perl)

[Wolfgang Maier]

On 11.03.2016 15:23, Fillmore wrote:

On 03/11/2016 07:13 AM, Wolfgang Maier wrote:

One lesson for Perl regex users is that in Python many things can be
solved without regexes.
How about defining:

printable = {chr(n) for n in range(32, 127)}

then using:

if (set(my_string) - set(printable)):
 break


seems computationally heavy. I have a file with about 70k lines, of
which only 20 contain "funny" chars.



Not sure what you call computationally heavy. I just test-parsed a 30 MB 
file (28k lines) with:


with open(my_file) as i:
for line in i:
if set(line) - printable:
continue

and it finished in less than a second.

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

Re: Encapsulation in Python

[jmp]

On 03/10/2016 02:41 PM, Ben Mezger wrote:

Hi all,

I've been studying Object Oriented Theory using Java. Theoretically, all
attributes should be private, meaning no one except the methods itself
can access the attribute;

public class Foo {
 private int bar;
 ...

Normally in Java, we would write getters and setters to set/get the
attribute bar. However, in Python, we normally create a class like so;

class Foo(object):
 bar = 0
 ...

And we usually don't write any getters/setters (though they exist in
Python, I have not seen much projects making use of it).

We can easily encapsulate (data hiding) Foo's class using the '_'
(underscore) when creating a new attribute, however, this would require
all attributes to have a underscore.
According to this answer [1], it's acceptable to to expose your
attribute directly (Foo.bar = 0), so I wonder where the encapsulation
happens in Python? If I can access the attribute whenever I want (with
the except of using a underscore), what's the best way to encapsulate a
class in Python? Why aren't most of the projects not using
getters/setters and instead they access the variable directly?

Regards,

Ben Mezger


Strictly speaking there is not such things as public/private attributes 
in python. All attributes are public.


'_' is just a (good) convention to tell the class users "don't mess with 
this attribute, don't read it nor write it".


And the python way is to stick to this, trust your users to not use your 
'private' attributes they've been warned.


Short story : in Python we don't hide, we flag.

JM

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

Re: non printable (moving away from Perl)

[Ian Kelly]

On Fri, Mar 11, 2016 at 9:34 AM, Wolfgang Maier
 wrote:
> On 11.03.2016 15:23, Fillmore wrote:
>>
>> On 03/11/2016 07:13 AM, Wolfgang Maier wrote:
>>>
>>> One lesson for Perl regex users is that in Python many things can be
>>> solved without regexes.
>>> How about defining:
>>>
>>> printable = {chr(n) for n in range(32, 127)}
>>>
>>> then using:
>>>
>>> if (set(my_string) - set(printable)):
>>>  break
>>
>>
>> seems computationally heavy. I have a file with about 70k lines, of
>> which only 20 contain "funny" chars.
>>
>
> Not sure what you call computationally heavy. I just test-parsed a 30 MB
> file (28k lines) with:
>
> with open(my_file) as i:
> for line in i:
> if set(line) - printable:
> continue
>
> and it finished in less than a second.

Did your test file contain on the order of 100 unique characters, or
on the order of 100,000?  Granted that most input data would likely
fall into the former category.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?

[BartC]

On 11/03/2016 05:29, Steven D'Aprano wrote:

On Fri, 11 Mar 2016 06:26 am, Mark Lawrence wrote:



No mention of speed anywhere, but then what does that silly old Tim
Peters know about anything?



The truth is, most people don't -- most Python code uses very little of the
dynamic features that get in the way of optimizing the interpreter, things
like intentionally shadowing or monkey-patching built-ins, adding
attributes to objects on the fly, or using exec and eval. In my dream
language, I wish that there were a way to tell the compiler "this is code
(function, class, module) is not dynamic, optimize it as much as you can".


The problem is the compiler has to have sight of the code for that to 
work. That means looking inside an imported module, which I think 
doesn't happen when running the byte-code compiler, but executing  the 
resulting byte-code.


Anyway, I've listed some of the stumbling blocks I think that Python has 
in making it bit faster: http://pastebin.com/WfUfK3bc


Solving all that won't magically make it a magnitude quicker, but 
noticeably brisker. And could open the way for further speed-ups. 
Unfortunately you can't these issues without radical changes to the 
language ...



Or better still, for the compiler itself to recognise when code is static,
and optimize it. Victor Stinner's FAT Python may be that compiler some day,
and I for one can't wait.


... unless you take the complicated approach as this project seems to!

(Mine would be to design the language to be less dynamic in the first 
place.)


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

Re: non printable (moving away from Perl)

[MRAB]

On 2016-03-11 00:07, Fillmore wrote:


Here's another handy Perl regex which I am not sure how to translate to
Python.

I use it to avoid processing lines that contain funny chars...

if ($string =~ /[^[:print:]]/) {next OUTER;}

:)


Python 3 (Unicode) strings have an .isprintable method:

mystring.isprintable()

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

Where is Python 3.6 installer for Win64?

[Giga Image]

On Soruceforge, Python for Windows Extension, I noticed that they already haven 
a installer for Python 3.6. 

Where do I find Python 3.6 installer for Win64. I couldn't find it on 
Python.org/download page.

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

Re: Where is Python 3.6 installer for Win64?

[Tim Golden]

On 11/03/2016 19:24, Giga Image wrote:

On Soruceforge, Python for Windows Extension, I noticed that they
already haven a installer for Python 3.6.

Where do I find Python 3.6 installer for Win64. I couldn't find it on
Python.org/download page.


The pywin32 crew are always ahead of the game: they build against the 
development branch of Python. We don't produce Windows installers for 
Python itself until the first betas / release candidates. If you 
*really* want to be that up-to-date you'll have to build for yourself.


If you're just looking to use a recent version of Python, stick to 3.5

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

Re: non printable (moving away from Perl)

[Fillmore]

On 3/11/2016 2:23 PM, MRAB wrote:

On 2016-03-11 00:07, Fillmore wrote:


Here's another handy Perl regex which I am not sure how to translate to
Python.

I use it to avoid processing lines that contain funny chars...

if ($string =~ /[^[:print:]]/) {next OUTER;}

:)


Python 3 (Unicode) strings have an .isprintable method:

mystring.isprintable()



my strings are UTF-8. Will it work there too?

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

issue with CVS module

[Fillmore]

I have a TSV file containing a few strings like this (double quotes are 
part of the string):


'"pragma: CacheHandler=08616B7E907744E026C9F044250EA55844CCFD52"'

After Python and the CVS module has read the file and re-printed the 
value, the string has become:


'pragma: CacheHandler=08616B7E907744E026C9F044250EA55844CCFD52'

which is NOT good for me. I went back to Perl and noticed that Perl was 
correctly leaving the original string intact.


This is what I am using to read the file:


with open(file, newline='') as csvfile:

myReader = csv.reader(csvfile, delimiter='\t')
for row in myReader:

and this is what I use to write the cell value

sys.stdout.write(row[0])

Is there some directive I can give CVS reader to tell it to stop 
screwing with my text?


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

Re: Where is Python 3.6 installer for Win64?

[Giga Image]

On Friday, March 11, 2016 at 11:38:09 AM UTC-8, Tim Golden wrote:
> On 11/03/2016 19:24, Giga Image wrote:
> > On Soruceforge, Python for Windows Extension, I noticed that they
> > already haven a installer for Python 3.6.
> >
> > Where do I find Python 3.6 installer for Win64. I couldn't find it on
> > Python.org/download page.
> 
> The pywin32 crew are always ahead of the game: they build against the 
> development branch of Python. We don't produce Windows installers for 
> Python itself until the first betas / release candidates. If you 
> *really* want to be that up-to-date you'll have to build for yourself.
> 
> If you're just looking to use a recent version of Python, stick to 3.5
> 
> TJG

Ok Thanks!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: non printable (moving away from Perl)

[Ben Finney]

Fillmore  writes:

> On 3/11/2016 2:23 PM, MRAB wrote:
> > Python 3 (Unicode) strings have an .isprintable method:
> >
> > mystring.isprintable()
>
> my strings are UTF-8. Will it work there too?

You need to always be clear on the difference between text (the Python 3
‘str’ type) versus bytes.

It only makes sense to talk about an encoding, when talking about bytes.

Text itself is an abstract data type; the content of a Unicode string
does not have any encoding because it is not encoded.

The content of a byte stream (such as a file's content) is not text, it
is bytes.

>>> foo = "こんにちは"
>>> foo.isprintable()
True

>>> foo_encoded = foo.encode("utf-8")
>>> foo_encoded.isprintable()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'bytes' object has no attribute 'isprintable'

You can only ask ‘isprintable’ about text. Bytes are not printable
because bytes are not text; you need to decode the bytes to text before
asking whether that text is printable.

>>> infile = open('lorem.txt', 'rb')
>>> infile_bytes = infile.read()
>>> infile_bytes.isprintable()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'bytes' object has no attribute 'isprintable'

>>> infile = open('lorem.txt', 'rt', encoding="utf-8")
>>> infile_text = infile.read()
>>> infile_text.isprintable()
True

-- 
 \“Telling pious lies to trusting children is a form of abuse, |
  `\plain and simple.” —Daniel Dennett, 2010-01-12 |
_o__)  |
Ben Finney

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

Re: issue with CVS module

[Joel Goldstick]

On Fri, Mar 11, 2016 at 2:41 PM, Fillmore 
wrote:

>
> I have a TSV file containing a few strings like this (double quotes are
> part of the string):
>
> '"pragma: CacheHandler=08616B7E907744E026C9F044250EA55844CCFD52"'
>
> After Python and the CVS module has read the file and re-printed the
> value, the string has become:
>
> 'pragma: CacheHandler=08616B7E907744E026C9F044250EA55844CCFD52'
>
> which is NOT good for me. I went back to Perl and noticed that Perl was
> correctly leaving the original string intact.
>
> This is what I am using to read the file:
>
>
> with open(file, newline='') as csvfile:
>
> myReader = csv.reader(csvfile, delimiter='\t')
> for row in myReader:
>
> and this is what I use to write the cell value
>
> sys.stdout.write(row[0])
>
> Is there some directive I can give CVS reader to tell it to stop screwing
> with my text?
>
> Thanks
> --
> https://mail.python.org/mailman/listinfo/python-list
>

Enter the python shell.  Import csv

then type help(csv)

It is highly configurable

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

Re: issue with CVS module

[Fillmore]

On 3/11/2016 3:05 PM, Joel Goldstick wrote:


Enter the python shell.  Import csv

then type help(csv)

It is highly configurable



Possibly, but I am having a hard time letting it know that it should 
leave each and every char alone, ignore quoting and just handle strings 
as strings. I tried playing with the quoting related parameters, to no 
avail:


Traceback (most recent call last):
  File "./myscript.py", line 47, in 
myReader = csv.reader(csvfile, delimiter='\t',quotechar='')
TypeError: quotechar must be set if quoting enabled

I tried adding CVS.QUOTE_NONE, but things get messy :(

Traceback (most recent call last):
  File "./myscript.py", line 64, in 
sys.stdout.write("\t"+row[h])
IndexError: list index out of range

Sorry for being a pain, but I am porting from Perl and  split 
/\t/,$line; was doing the job for me. Maybe I should go back to split on 
'\t' for python too...


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

Re: issue with CVS module

[Fillmore]

On 3/11/2016 2:41 PM, Fillmore wrote:

Is there some directive I can give CVS reader to tell it to stop
screwing with my text?


OK, I think I reproduced my problem at the REPL:

>>> import csv
>>> s = '"Please preserve my doublequotes"\ttext1\ttext2'
>>> reader = csv.reader([s], delimiter='\t')
>>> for row in reader:
... print(row[0])
...
Please preserve my doublequotes
>>>

:(

How do I instruct the reader to preserve my doublequotes?

As an aside. split() performs the job correctly...

>>> allVals = s.split("\t")
>>> print(allVals[0])
"Please preserve my doublequotes"
>>>


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

Re: issue with CVS module

[mm0fmf]

On 11/03/2016 20:32, Fillmore wrote:

myReader = csv.reader(csvfile, delimiter='\t',quotechar='')


From reading that the quotechar is null. You have a single quote and 
single quote with nothing in the middle.


Try this:

myReader = csv.reader(csvfile, delimiter='\t',quotechar="'")

i.e doublequote singlequote doublequote

or the other way

myReader = csv.reader(csvfile, delimiter='\t',quotechar='"')

I haven't tried this, so it may be nonsense.

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

Re: issue with CVS module

[Ben Finney]

Fillmore  writes:

> Possibly, but I am having a hard time letting it know that it should
> leave each and every char alone

You're using the wrong module, then. To use the ‘csv’ module is to have
the sequence of characters parsed to extract component values, which
cannot also “leave each and every character alone”.

If you want to “leave each and every character alone”, don't parse the
data as CSV. Instead, read the file as a simple text file.

-- 
 \   “I have always wished for my computer to be as easy to use as |
  `\   my telephone; my wish has come true because I can no longer |
_o__)  figure out how to use my telephone.” —Bjarne Stroustrup |
Ben Finney

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

Re: issue with CVS module

[MRAB]

On 2016-03-11 20:49, Fillmore wrote:

On 3/11/2016 2:41 PM, Fillmore wrote:

Is there some directive I can give CVS reader to tell it to stop
screwing with my text?


OK, I think I reproduced my problem at the REPL:

  >>> import csv
  >>> s = '"Please preserve my doublequotes"\ttext1\ttext2'
  >>> reader = csv.reader([s], delimiter='\t')
  >>> for row in reader:
... print(row[0])
...
Please preserve my doublequotes
  >>>

:(

How do I instruct the reader to preserve my doublequotes?

As an aside. split() performs the job correctly...

  >>> allVals = s.split("\t")
  >>> print(allVals[0])
"Please preserve my doublequotes"
  >>>


>>> import csv
>>> s = '"Please preserve my doublequotes"\ttext1\ttext2'
>>> reader = csv.reader([s], delimiter='\t', quotechar=None)
>>> for row in reader:
... print(row[0])
...
"Please preserve my doublequotes"
>>>

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

Re: issue with CVS module

[Mark Lawrence]

On 11/03/2016 19:41, Fillmore wrote:


I have a TSV file containing a few strings like this (double quotes are
part of the string):

'"pragma: CacheHandler=08616B7E907744E026C9F044250EA55844CCFD52"'

After Python and the CVS module has read the file and re-printed the
value, the string has become:

'pragma: CacheHandler=08616B7E907744E026C9F044250EA55844CCFD52'

which is NOT good for me. I went back to Perl and noticed that Perl was
correctly leaving the original string intact.

This is what I am using to read the file:


with open(file, newline='') as csvfile:

 myReader = csv.reader(csvfile, delimiter='\t')
 for row in myReader:

and this is what I use to write the cell value

 sys.stdout.write(row[0])

Is there some directive I can give CVS reader to tell it to stop
screwing with my text?

Thanks


https://docs.python.org/3/library/csv.html#csv.Dialect.doublequote

--
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: issue with csv module (subject module name spelling correction, too)

[Martin A. Brown]

Good afternoon Fillmore,

 import csv
 s = '"Please preserve my doublequotes"\ttext1\ttext2'
 reader = csv.reader([s], delimiter='\t')

> How do I instruct the reader to preserve my doublequotes?

Change the quoting used by the dialect on the csv reader instance:

  reader = csv.reader([s], delimiter='\t', quoting=csv.QUOTE_NONE)

You can use the same technique for the writer.

If you cannot create your particular (required) variant of csv by 
tuning the available parameters in the csv module's dialect control, 
I'd be a touch surprised, but, it is possible that your other csv
readers and writers are more finicky.

Did you see the parameters that are available to you for tuning how 
the csv module turns your csv data into records?

  https://docs.python.org/3/library/csv.html#dialects-and-formatting-parameters

Judging from your example, you definitely want to use 
quoting=csv.QUOTE_NONE, because you don't want the module to do much 
more than split('\t').

Good luck,

-Martin

-- 
Martin A. Brown
http://linux-ip.net/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: issue with CVS module

[Fillmore]

On 3/11/2016 4:14 PM, MRAB wrote:



 >>> import csv
 >>> s = '"Please preserve my doublequotes"\ttext1\ttext2'
 >>> reader = csv.reader([s], delimiter='\t', quotechar=None)
 >>> for row in reader:
... print(row[0])
...
"Please preserve my doublequotes"
 >>>



This worked! thank you MRAB


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

Re: issue with CVS module

[Fillmore]

On 3/11/2016 4:15 PM, Mark Lawrence wrote:


https://docs.python.org/3/library/csv.html#csv.Dialect.doublequote



thanks, but my TSV is not using any particular dialect as far as I 
understand...


Thank you, anyway


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

Re: issue with CVS module

[Fillmore]

On 3/11/2016 2:41 PM, Fillmore wrote:


I have a TSV file containing a few strings like this (double quotes are
part of the string):



A big thank you to everyone who helped with this and with other 
questions. My porting of one of my Perl scripts to Python is over now 
that the two scripts produce virtually the same result:


$ wc -l test2.txt test3.txt
   70823 test2.txt
   70822 test3.txt
  141645 total
$ diff test2.txt test3.txt
69351d69350
<

there's only an extra empty line at the bottom that I'll leave as a tip 
to Perl ;)


It was instructive.



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

The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Chris Angelico]

On Sat, Mar 12, 2016 at 5:57 AM, BartC  wrote:
> Anyway, I've listed some of the stumbling blocks I think that Python has in
> making it bit faster: http://pastebin.com/WfUfK3bc
>

Much easier to discuss text that's inline, so I'm taking this out of pastebin.

> Functions are dynamic. That is, you don't know the F in F() is actually a 
> function, even if it was defined a few lines previously, because it could 
> have been rebound to something else. That means a runtime check to ensure 
> that it is one.
>
> * Dynamic functions mean the compiler doesn't know how many parameters a 
> function takes. This needs checking at runtime, and something done about too 
> many or too few arguments.
>
> * The compiler doesn't know the names of the parameters in the function it's 
> calling. So keyword arguments need to be dealt with at runtime.
>
> * The compiler doesn't know about parameter default values, so again this 
> needs to be checked and dealt with at runtime
>

All of these are really one thing: When you compile some code, you
don't know whether F() is still going to be the same object when you
run it. FAT Python is intended to pick this up; it recognizes
constants, and can then perform all the other optimizations you
describe (since functions are themselves immutable, all you need is an
identity check on the function object itself, and everything else you
describe can be done safely).

> * Top-level names (eg. the 'A' in A.B.C), which generally refer to a defined 
> function, class or module, or to a variable, can additionally be deleted or 
> added at runtime. This means a look-up for such names (LOAD_GLOBAL), if they 
> are not local to a function.
>
> * Module names are dynamic. So for a call such as M.F(), M needs to be looked 
> up (M could be a number of things), and then an attribute lookup for F needs 
> to be done before a call can be made. Then you have those other matters above.
 >
> (Static modules and functions would mean that M.F() can be resolved at 
> compile-time. No name or attribute lookup needed, and in fact the function 
> can be an operand of a Call byte-code with no need to load to the stack 
> first.)
>
> * Dynamic modules mean it is not possible to optimise expressions using 
> math.sqrt() for example, as both math and sqrt could have been changed.
>

Not sure what the significance of this is. Since they can be rebound
at run-time, you need a lookup anyway. The only way to avoid that
lookup is to constant-fold them, which would break anything that
*ever* rebinds globals. But again, FAT Python is looking into this
(since the rebinding of globals is unusual). The same thing applies to
module attributes, since your globals are simply the attributes of
your module, and "math.sqrt()" is just a special case of M.F().

> * Variables are dynamic. So you can't for example declare (with a new const 
> feature) 'const rows=50', which would allow you to code 'LOAD_CONST' instead 
> of 'LOAD_GLOBAL', or even to eliminate it completely as some expressions 
> could be folded.
>
> * Enum names are dynamic. There are a number of ways of having enumerations, 
> but they are all going to suffer from the same problem of names possibly 
> being rebound to something else. That means executing LOAD_GLOBAL or doing 
> attribute lookups, instead of LOAD_CONST.
>

Definitely agree with this. Having a way to declare that a name is
"truly constant" would be extremely handy; there currently isn't a
way, and I'm not sure whether FAT Python is looking into this or not.
I think it's more focusing on the situation where something simply has
never been rebound, which is probably the better optimization; but
sometimes it'd be nice to be able to assert that something *will not*
be rebound, to help with self-documenting code. (Note that "constant"
implies both "never rebound" and "immutable". I actually don't care
about the latter; you could, for instance, declare that "sys.path" is
a constant list, which means you're not allowed to replace it with a
different list, but are allowed to append to it or remove from it.)

>  * Without a way of defining compile-time constants, very useful language 
> features such as 'switch' are not practical.

Maybe, but I honestly don't miss 'switch' all that often - and when I
do, it's usually because I want a range. Consider this
semi-hypothetical Pike code:

switch (key)
{
case 'A'..'Z': case 'a'..'z': return "Letter";
case 0xFF00..0x: return "Special key";
case '.': case ',': case '!': return "Punctuation";
default: return "Other";
}

With a small number of cases, this wouldn't be too bad in if/elif
form; but as it gets bigger, the value of a switch block becomes
evident. The normal advice in Python is "use a dispatch dictionary",
but that would be impractical here. So this would end up being a
massive if/elif tree, because there's just no better way to do this.

> * Python 3 has decided to have a single 'long' type for integers, instead of 
> separate int (32 or

hasattr() or "x in y"?

[Charles T. Smith]

>From the performance point of view, which is better:
- hasattr()
- x in y

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

Re: hasattr() or "x in y"?

[Chris Angelico]

On Sat, Mar 12, 2016 at 8:44 AM, Charles T. Smith
 wrote:
> From the performance point of view, which is better:
> - hasattr()
> - x in y
>

Mu. They do completely different things.

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

Re: hasattr() or "x in y"?

[Charles T. Smith]

On Fri, 11 Mar 2016 21:44:27 +, Charles T. Smith wrote:

> From the performance point of view, which is better: - hasattr()
> - x in y
> 
> TIA
> cts


I just realized that "in" won't look back through the class hierarchy...
that clearly makes them not interchangable, but given we're only
interested in the current dict...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?

[Mark Lawrence]

On 11/03/2016 18:57, BartC wrote:


Anyway, I've listed some of the stumbling blocks I think that Python has
in making it bit faster: http://pastebin.com/WfUfK3bc



The String Append Benchmark

This is a microbenchmark, but makes use of a technique I use extensively 
(creating a file for example by growing a string a character at a time).


def test():
s=""
for i in range(1000):
s+="*"
print (len(s))

test()


The minor snag that you might like to correct with your microbenchmark, 
which any experienced Python programmer knows, is that you *NEVER, EVER* 
create strings like this.  Given that you've admitted earlier today that 
you couldn't get a simple slice to work, how much, if anything, do you 
actually know about Python?


--
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: hasattr() or "x in y"?

[Chris Angelico]

On Sat, Mar 12, 2016 at 8:53 AM, Charles T. Smith
 wrote:
> On Fri, 11 Mar 2016 21:44:27 +, Charles T. Smith wrote:
>
>> From the performance point of view, which is better: - hasattr()
>> - x in y
>>
>> TIA
>> cts
>
>
> I just realized that "in" won't look back through the class hierarchy...
> that clearly makes them not interchangable, but given we're only
> interested in the current dict...

They're still completely different - hasattr looks at attributes, but
the 'in' operator looks at the object's members (in the case of a
dictionary, the keys). There is a broad similarity between
"hasattr(obj, attrname)" and "attrname in obj.__dict__", but if you're
doing the latter, you have other problems than performance; attributes
should be looked up as attributes, not as dictionary members.

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

Re: hasattr() or "x in y"?

[Mark Lawrence]

On 11/03/2016 21:53, Charles T. Smith wrote:

On Fri, 11 Mar 2016 21:44:27 +, Charles T. Smith wrote:


 From the performance point of view, which is better: - hasattr()
- x in y

TIA
cts



I just realized that "in" won't look back through the class hierarchy...
that clearly makes them not interchangable, but given we're only
interested in the current dict...



Dict, don't you mean collection?  Or, to put it another way, what 
exactly were you originally asking?


--
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: hasattr() or "x in y"?

[Grant Edwards]

On 2016-03-11, Charles T. Smith  wrote:
> From the performance point of view, which is better:

> - hasattr()
> - x in y

Dunno, is red an even or odd color?  How many pancakes does it take to
cover a doghouse?

>>> "x" in "asdf"
False
>>> "x" in "xyz"
True

>>> "asdf".hasattr("x")
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'str' object has no attribute 'hasattr'
>>> "xyz".hasattr("x")
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'str' object has no attribute 'hasattr'

Since they behave differently, perhaps the question ought to be "which
does what you want to do?"

-- 
Grant Edwards   grant.b.edwardsYow! I had pancake makeup
  at   for brunch!
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: hasattr() or "x in y"?

[Mark Lawrence]

On 11/03/2016 22:00, Grant Edwards wrote:

On 2016-03-11, Charles T. Smith  wrote:

 From the performance point of view, which is better:



- hasattr()
- x in y


Dunno, is red an even or odd color?  How many pancakes does it take to
cover a doghouse?


"x" in "asdf"

False

"x" in "xyz"

True


"asdf".hasattr("x")

Traceback (most recent call last):
   File "", line 1, in 
AttributeError: 'str' object has no attribute 'hasattr'

"xyz".hasattr("x")

Traceback (most recent call last):
   File "", line 1, in 
AttributeError: 'str' object has no attribute 'hasattr'

Since they behave differently, perhaps the question ought to be "which
does what you want to do?"



The BartC answer would be that it doesn't matter provided it runs 
quickly.  The RUE answer would be that he can't get it to work anyway 
because of the Python3 FSR.  RR I'm not sure about.  Mark Janssen would 
state that Python shouldn't have an object called 'str', and Ilias 
Lazaridis would still be evaluating and hence wouldn't have made up his 
mind.  Who have I missed?  Ah, I remember, that Dutch idiot who created 
a programming language that was so useless it only lasted for 25 years. 
 Now what was his name, and what was the name of the language?


--
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: hasattr() or "x in y"?

[Charles T. Smith]

On Fri, 11 Mar 2016 22:00:41 +, Grant Edwards wrote:

> Since they behave differently, perhaps the question ought to be "which
> does what you want to do?"

For parsed msgs, I had this:

  elif hasattr (msg.msgBody, 'request'):

It occurred to me that this was less abstruse:

  elif 'request' in msg.msgBody:

and by the way, how would you do that with duck-typing?
If I were doing this anew, I probably use a dictionary of functors,
but that's not an option anymore.
  
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?

[BartC]

On 11/03/2016 21:59, Mark Lawrence wrote:

On 11/03/2016 18:57, BartC wrote:



def test():
 s=""
 for i in range(1000):
 s+="*"
 print (len(s))

test()



The minor snag that you might like to correct with your microbenchmark,
which any experienced Python programmer knows, is that you *NEVER, EVER*
create strings like this.


Why not? Chris said his version runs much faster (even allowing for 
different machines), and might have a special optimisation for it.


And I think it can be optimised if, for example, there are no other 
references to the string that s refers to.


So what's wrong with trying to fix it rather that using a workaround?

--
Bartc

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

Re: hasattr() or "x in y"?

[Grant Edwards]

On 2016-03-11, Charles T. Smith  wrote:
> On Fri, 11 Mar 2016 22:00:41 +, Grant Edwards wrote:
>
>> Since they behave differently, perhaps the question ought to be "which
>> does what you want to do?"
>
> For parsed msgs, I had this:
>
>   elif hasattr (msg.msgBody, 'request'):
>
> It occurred to me that this was less abstruse:
>
>   elif 'request' in msg.msgBody:

If you want to know if msg.msgBody has an attribute named 'request'
then use hasattr().

If you want to know if msg.msgBody "contains"[1] the string 'request'
then use "in".

_They're_two_different_things_

[1] for some definition of "contains" that depends on the type of
msg.msgBody.

> and by the way, how would you do that with duck-typing?

Do WHAT?

> If I were doing this anew, I probably use a dictionary of functors,
> but that's not an option anymore.

-- 
Grant Edwards   grant.b.edwardsYow! Were these parsnips
  at   CORRECTLY MARINATED in
  gmail.comTACO SAUCE?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?

[Mark Lawrence]

On 11/03/2016 22:24, BartC wrote:

On 11/03/2016 21:59, Mark Lawrence wrote:

On 11/03/2016 18:57, BartC wrote:



def test():
 s=""
 for i in range(1000):
 s+="*"
 print (len(s))

test()



The minor snag that you might like to correct with your microbenchmark,
which any experienced Python programmer knows, is that you *NEVER, EVER*
create strings like this.


Why not? Chris said his version runs much faster (even allowing for
different machines), and might have a special optimisation for it.

And I think it can be optimised if, for example, there are no other
references to the string that s refers to.

So what's wrong with trying to fix it rather that using a workaround?



The mere fact that you have to ask indicates quite clearly that you know 
nothing about Python.  I'm not going to spoon feed you, go and do your 
own research.


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

[Larry Martell]

On Fri, Mar 11, 2016 at 4:49 AM, Steven D'Aprano 
wrote:

> On Fri, 11 Mar 2016 02:28 pm, rubengoods...@yahoo.com wrote:
>
> > I am having trouble installing the Python software.
>
> Make sure your computer is turned on. I can't tell you how many times I've
> tried to install Python, and I type commands and click icons and nothing
> happens. It's really frustrating when you finally realise that the reason
> nothing is working is because the computer is turned off! (I thought I just
> had the screen brightness turned way down.)


Many years ago (c. 1985) I was at a job interview and the interviewer asked
me what the first thing I would do when I am presented with a new problem
that I had to code up. I gave all sorts of answers like 'do a top down
analysis of the problem,' and 'get the specs and requirements,' and 'write
a flow chart.' Each time the interviewer said no even before that. Finally
I said, what, what would do first? He said "Turn the computer on." I
decided then and there I did not want to work for that guy.
-- 
https://mail.python.org/mailman/listinfo/python-list

argparse

[Fillmore]

Playing with ArgumentParser. I can't find a way to override the -h and 
--help options so that it provides my custom help message.


  -h, --help show this help message and exit

Here is what I am trying:

parser = argparse.ArgumentParser("csresolver.py",add_help=False)
parser.add_argument("-h","--help",
help="USAGE:  | myscript.py [-exf Exception 
File]")

parser.add_argument("-e","--ext", type=str,
help="Exception file")
args = parser.parse_args()


The result:

$ ./myscript.py -h
usage: myscript.py [-h HELP] [-e EXT]
csresolver.py: error: argument -h/--help: expected one argument

am I missing something obvious?


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

Re: argparse

[Bob Gailer]

On Mar 11, 2016 6:20 PM, "Fillmore"  wrote:
>
>
> Playing with ArgumentParser. I can't find a way to override the -h and
--help options so that it provides my custom help message.
>
>   -h, --help show this help message and exit
>
> Here is what I am trying:
>
> parser = argparse.ArgumentParser("csresolver.py",add_help=False)
> parser.add_argument("-h","--help",
> help="USAGE:  | myscript.py [-exf Exception
File]")
> parser.add_argument("-e","--ext", type=str,
> help="Exception file")
> args = parser.parse_args()
Just a guess- put "h","--help" in ()
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: argparse

[Larry Martell]

On Fri, Mar 11, 2016 at 6:18 PM, Fillmore  wrote:
>
>
> Playing with ArgumentParser. I can't find a way to override the -h and --help 
> options so that it provides my custom help message.
>
>   -h, --help show this help message and exit
>
> Here is what I am trying:
>
> parser = argparse.ArgumentParser("csresolver.py",add_help=False)
> parser.add_argument("-h","--help",
> help="USAGE:  | myscript.py [-exf Exception File]")
> parser.add_argument("-e","--ext", type=str,
> help="Exception file")
> args = parser.parse_args()
>
>
> The result:
>
> $ ./myscript.py -h
> usage: myscript.py [-h HELP] [-e EXT]
> csresolver.py: error: argument -h/--help: expected one argument
>
> am I missing something obvious?

https://docs.python.org/2/library/argparse.html#usage
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: argparse

[Fillmore]

On 3/11/2016 6:26 PM, Larry Martell wrote:

am I missing something obvious?


https://docs.python.org/2/library/argparse.html#usage



you rock!



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

Re: argparse

[Ian Kelly]

On Fri, Mar 11, 2016 at 4:18 PM, Fillmore  wrote:
>
> Playing with ArgumentParser. I can't find a way to override the -h and
> --help options so that it provides my custom help message.
>
>   -h, --help show this help message and exit
>
> Here is what I am trying:
>
> parser = argparse.ArgumentParser("csresolver.py",add_help=False)
> parser.add_argument("-h","--help",
> help="USAGE:  | myscript.py [-exf Exception
> File]")
> parser.add_argument("-e","--ext", type=str,
> help="Exception file")
> args = parser.parse_args()
>
>
> The result:
>
> $ ./myscript.py -h
> usage: myscript.py [-h HELP] [-e EXT]
> csresolver.py: error: argument -h/--help: expected one argument
>
> am I missing something obvious?

Larry gave you the right way to do this. However I wanted to also
point out that the reason you're getting an error is because you
didn't specify an action or an nargs for the argument. The default
action is store, and the default nargs for that action is 1, so
argparse is expecting to find one argument after your -h.
-- 
https://mail.python.org/mailman/listinfo/python-list

Perl to Python again

[Fillmore]

So, now I need to split a string in a way that the first element goes 
into a string and the others in a list:


while($line = ) {

my ($s,@values)  = split /\t/,$line;

I am trying with:

for line in sys.stdin:
s,values = line.strip().split("\t")
print(s)

but no luck:

ValueError: too many values to unpack (expected 2)

What's the elegant python way to achieve this?

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

Re: Hello

[Steven D'Aprano]

On Sat, 12 Mar 2016 09:53 am, Larry Martell wrote:

> Many years ago (c. 1985) I was at a job interview and the interviewer
> asked me what the first thing I would do when I am presented with a new
> problem that I had to code up. I gave all sorts of answers like 'do a top
> down analysis of the problem,' and 'get the specs and requirements,' and
> 'write a flow chart.' Each time the interviewer said no even before that.
> Finally I said, what, what would do first? He said "Turn the computer on."
> I decided then and there I did not want to work for that guy.


I'm reminded of a wonderful scene from an old movie called "Those
Magnificent Men In Their Flying Machines". Set some time in the early 20th
century, before World War 1, it's about an international aeroplane race
across the English Channel. One of the pilots is an Englishman, played by
Terry Thomas, who of course plays a bounder and a cad, so he tries to
sabotage the other contestants so he can win the race. He manages to give
the German pilot an overdose of laxative to put him out of the race.

The German's commanding officer, a great big fat Prussian colonel, decides
that with German discipline and planning anyone can be a pilot, so he takes
the German army Flying Machine instruction manual, climbs into the plane's
cockpit, and standing proudly, opens the book to the first page and reads:

[Hollywood German accent]
"Step One: Sit Down!"





-- 
Steven

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

Re: Encapsulation in Python

[Rick Johnson]

On Thursday, March 10, 2016 at 1:36:48 PM UTC-6, Mark Lawrence wrote:
> On 10/03/2016 14:57, Dan Strohl via Python-list wrote:
> >> I've been studying Object Oriented Theory using Java. Theoretically, all
> >> attributes should be private, meaning no one except the methods itself can
> >> access the attribute;
> >>
> >> public class Foo {
> >>  private int bar;
> >>  ...
> >
> 
> For the benefit of any newbies/lurkers I'll just point out
> that this might well be valid Java, but...
> 
> > class person:
> >   age = 21
> >   name = 'Cool Dude'
> >
> ...this gives you class attributes, so the age is always
> 21 and the name is always 'Cool Dude'.  So you can vary
> the age and name you'd need:-
> 
> class person():
>  def __init__(self, age, name):
>  self.age = age
>  self.name = name

Mark, you've made some absurd claims in the past, but are
you *REALLY* expecting this group of highly intelligent
people to believe, that class attributes are read-only? 


# BEGIN INTERACTIVE SESSION

PY> class Foo(object):
... age=21
... name = 'cool dude'
... 
PY> Foo.name
cool dude
PY> Foo.age
21
PY> Foo.age = 25
PY> Foo.age
25

# END INTERACTIVE SESSION


And furthermore, do you realize that the "new code" you
posted, creates instance level variables, *NOT* class level
variables?


# BEGIN INTERACTIVE SESSION

PY> class Foo(object):
... def __init__(self, name, age):
... self.name = name
... self.age = age
... 
PY> Foo.name
AttributeError: type object 'Foo' has no attribute 'name'

PY> Foo.age
AttributeError: type object 'Foo' has no attribute 'age'

# END INTERACTIVE SESSION


Of course, "name" and "age" would be more appropriate when
defined as instance variables, since both are attributes
specific to each person. A class level variable should only
be used for an attribute that is shared by *ALL* instances
of the class, and one that is *NOT* specific to any one of
them.

For instance, something highly general like keeping a tally
of the total number of "Persons" created, or the total
number of persons with red hair, or with green eyes. These
are the more generalized attributes of *ALL* persons, that
are not specific to any *ONE* person.

By offering example code that attempts to initialize class
level variables in the constructor, you have exposed yourself
as not understanding what a class level variable *IS*. You
*DON'T* initialize class level variables, no, you assign them
to the class object. Class level variables are intended to
be used as "shared state" between multiple instances, not
"initialized" by each instance.

But don't feel bad. Most folks would be surprised at the
high percentage of "seasoned programmers" who do not
understand the difference between class level, and instance
level variables. I've have personally witnessed someone say
aloud: "Class variables are useless, always use instance
variables instead".

Oh my! o_O

There are two types of variables you can create relative to
a class: instance level variables, and class level
variables. In python, both of them can be read and written at
will, however, creating them and accessing them is slightly
different.

PS: Ignorance of the unknown produces fear, and fear can
produce unwarranted hatred. I have suspected for many years
that those in the Python community who are constantly bad-
mouthing OOP, are displaying an emotional reaction rooted in
the psychological distress of ignorance and fear, and your 
posting here has provided evidence of that distress.

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

Re: Perl to Python again

[sohcahtoa82]

On Friday, March 11, 2016 at 3:42:36 PM UTC-8, Fillmore wrote:
> So, now I need to split a string in a way that the first element goes 
> into a string and the others in a list:
> 
> while($line = ) {
> 
>  my ($s,@values)  = split /\t/,$line;
> 
> I am trying with:
> 
> for line in sys.stdin:
>  s,values = line.strip().split("\t")
>  print(s)
> 
> but no luck:
> 
> ValueError: too many values to unpack (expected 2)
> 
> What's the elegant python way to achieve this?
> 
> Thanks

I'd call the split, assign it to a temp value, then pull from there, like this:

parts = line.strip().split('\t')
s = parts[0]
values = parts[1:]

There might be a one-line way to do it, but I can't think of one that doesn't 
rely on calling split() twice.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Perl to Python again

[Martin A. Brown]

Good afternoon Fillmore,

> So, now I need to split a string in a way that the first element 
> goes into a string and the others in a list:
>
> while($line = ) {
>
>my ($s,@values)  = split /\t/,$line;
>
> I am trying with:
>
> for line in sys.stdin:
>s,values = line.strip().split("\t")
>print(s)
>
> but no luck:
>
> ValueError: too many values to unpack (expected 2)

That means that the number of items on the right hand side of the 
assignment (returned from the split() call) did not match the number 
of variables on the left hand side.

> What's the elegant python way to achieve this?

Are you using Python 3?

  s = 'a,b,c,d,e'
  p, *remainder = s.split(',')
  assert isinstance(remainder, list)

Are you using Python 2?

  s = 'a,b,c,d,e'
  remainder = s.split(',')
  assert isinstance(remainder, list)
  p = remainder.pop(0)

Aside from your csv question today, many of your questions could be 
answered by reading through the manual documenting the standard 
datatypes (note, I am assuming you are using Python 3).

  https://docs.python.org/3/library/stdtypes.html

It also sounds as though you are applying your learning right away.  
If that's the case, you might also benefit from reading through all 
of the services that are provided in the standard library with 
Python:

  https://docs.python.org/3/library/

In terms of thinking Pythonically, you may benefit from:

  The Python Cookbook (O'Reilly)
  http://shop.oreilly.com/product/0636920027072.do

  Python Module of the Week
  https://pymotw.com/3/

I'm making those recommendations because I know and have used these 
and also because of your Perl background.

Good luck,

-Martin

-- 
Martin A. Brown
http://linux-ip.net/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Perl to Python again

[Fillmore]

On 3/11/2016 7:12 PM, Martin A. Brown wrote:


Aside from your csv question today, many of your questions could be
answered by reading through the manual documenting the standard
datatypes (note, I am assuming you are using Python 3).



are you accusing me of being lazy?

if that's your accusation, then guilty as charged, but

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

Re: Where is Python 3.6 installer for Win64?

[Terry Reedy]

On 3/11/2016 2:37 PM, Tim Golden wrote:

On 11/03/2016 19:24, Giga Image wrote:

On Soruceforge, Python for Windows Extension, I noticed that they
already haven a installer for Python 3.6.

Where do I find Python 3.6 installer for Win64. I couldn't find it on
Python.org/download page.


The pywin32 crew are always ahead of the game: they build against the
development branch of Python. We don't produce Windows installers for
Python itself until the first betas / release candidates.


There are also installers for alpha releases.  The first alpha is 
scheduled for May 15, 2016.



--
Terry Jan Reedy

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

Re: Encapsulation in Python

[Rick Johnson]

On Friday, March 11, 2016 at 3:28:40 AM UTC-6, Steven D'Aprano wrote:

> That's one theory. Another theory is: no they shouldn't, all attributes
> should be public. That most accurately models actual physical objects and
> maximizes the usefulness of the attribute.
> 
> People over-use private, and if you google, you will find many people
> asking "how can I access private variables and methods?".

If "people" are trying to access private variables, then one, or both, 
of these  has occurred: (1) The interface was poorly
written, and/or (2) The user of the interface is hell bent
on shooting himself in the foot!

> Python offers a middle ground: where encapsulation is important for safety,
> use it, otherwise rely on trust and a gentleman's agreement. We're all
> adults here: if you use my internals, that's your choice, and you can live
> with the consequences.
> 
> In practice this means that internal details of classes written in C are
> completely hidden from Python code unless explicitly made public. Why?
> Because if the caller messes with the internal data of a C class, they can
> cause a segmentation fault, which can execute arbitrary code. This is a
> serious problem, and Python has a philosophy of Absolutely No Seg Faults.

First you go off blabbing about how all attributes should be
public, then you do an about face, and admit that very bad
things can happen when internals are exposed. Does anyone
else find this argument to be absurd?

> It should be impossible to cause the Python interpreter to seg fault or
> dump core (except via ctypes, which is special). 

SPECIAL CASES ARE *NOT* SPECIAL ENOUGH TO BREAK THE RULES!

> But what about Python classes? You can't cause a seg fault in Python code.

Are you sure about that? Heck, i posted code quite a few
years back that "seg faulted like a mutha". Do you want to
retract your statement, or will i need to search the
archives, and then stuff the link down your big fat mouth?

> So Python's philosophy is:
> 
> - trying to *enforce* private data is a waste of time, people will find a
> way around it, even if it is a horrible nasty hack;
> 
> - so instead, rely on trust: we mark "private" attributes with a leading
> underscore, and trust that users won't abuse them;
> 
> - if they do, the consequences are on their head, not ours: you have no
> responsibility to users who misuse your private attributes.

I theory, that is a great philosophy, but in practice, it
encourages people to be lazy, and they end up writing
horrible interfaces. Why spend the time to write a proper
interface, when, in the back of your mind, you know you can
reach into that public cookie jar *ANYTIME* you want to.
It's like when an overweight person goes on a diet, but still 
has cookies, cakes and ice-cream in the kitchen -- the
temptation to be a slob is just too great!

Imagine if indention were optional in Python, or if Python
allowed braces... Even with all the benefits of indention
over braces, quite a few idiots would still use the damn
braces! Heck, i knew this one Ruby coder, who was a longtime
C coder, and at the end of every line, he religiously placed
a semicolon there. And i told him, "dude, you're *NOT*
writing C code anymore, so stop putting those damn trailing
semicolons in your source!". But the arrogant bassturd
refused to stop. So i thought: "Hmm, maybe it's just a bad
habit", but no, he freely admitted that he conscientiously
placed them in hos source because: "he liked them".

There are two main methods that a language can ruin you as a
programmer. One method is to encourage you to be a "Lazy
Larry", and the other is to mold you into a "habitual
Harry". Python has mostly eradicated the "habitual Harry"
disease, but it still actively promotes the "lazy Larry"
disease. Yes, pure OOP is onerous to the programmer, but it
is onerous for a reason. And that *REASON* is to create
rigid interfaces!

Anytime a standard is handed down, people are going to
whine.

 "WAH, standards are hard!"
 
 "WAH, it takes too long!" 
 
 "WAH, my fingers hurt!"
 
But what these whiners don't realize, is that, either they
put in the effort of writing solid interfaces *NOW*, or they
will be forced to debug, explain, and repair the awful
interfaces *LATER*.  In the end, there is no shortcut to
excellence. Which brings me back to my motto: "Great
interfaces *NEVER* happen by accident --shite happens,
interfaces don't!"

Yes, creating proper interfaces requires a lot of thought, a
lot of testing, and yes, a whle lot of typing. But if
thinking, and testing, and typing are not your thing, then
perhaps you'd be happier smoking marijuana and working as
sales associate at your local GAP store.

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

Re: Encapsulation in Python

[Gregory Ewing]

Rick Johnson wrote:

I have witnessed the mayhem that occurs when a language does
not mandate module encapsulation (Ruby, i'm looking directly
at you), and while i agree with the Python designers
that modules must *ALWAYS* be mandatory, i am not convinced
that module space should be so strictly confined to source
files.


Well, I am. When looking at someone else's code, it's
very useful to be able to take a name used in one source
file and easily find the file where it's defined. That's
very easy to do in Python, and very hard to do in languages
that don't relate namespaces and source files.

The experiences I base this on aren't confined to Python.
This is one of the very few things that I think Java got
right, and some of the other JVM-based languages -- such
as Scala -- got wrong.

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

Re: Encapsulation in Python

[Rick Johnson]

(NOTE: My apologies to the group if this same message was sent twice. From my 
end, it appears to have been lost, so i'm sending again. Thanks)

On Thursday, March 10, 2016 at 1:36:48 PM UTC-6, Mark Lawrence wrote:
> On 10/03/2016 14:57, Dan Strohl via Python-list wrote:
> >> I've been studying Object Oriented Theory using Java. Theoretically, all
> >> attributes should be private, meaning no one except the methods itself can
> >> access the attribute;
> >>
> >> public class Foo {
> >>  private int bar;
> >>  ...
> >
> 
> For the benefit of any newbies/lurkers I'll just point out
> that this might well be valid Java, but...
> 
> > class person:
> >   age = 21
> >   name = 'Cool Dude'
> >
> ...this gives you class attributes, so the age is always
> 21 and the name is always 'Cool Dude'.  So you can vary
> the age and name you'd need:-
> 
> class person():
>  def __init__(self, age, name):
>  self.age = age
>  self.name = name

Mark, you've made some absurd claims in the past, but are
you *REALLY* expecting this group of highly intelligent
people to believe, that class attributes are read-only? 


# BEGIN INTERACTIVE SESSION

PY> class Foo(object):
... age=21
... name = 'cool dude'
... 
PY> Foo.name
cool dude
PY> Foo.age
21
PY> Foo.age = 25
PY> Foo.age
25

# END INTERACTIVE SESSION


And furthermore, do you realize that the "new code" you
posted, creates instance level variables, *NOT* class level
variables?


# BEGIN INTERACTIVE SESSION

PY> class Foo(object):
... def __init__(self, name, age):
... self.name = name
... self.age = age
... 
PY> Foo.name
AttributeError: type object 'Foo' has no attribute 'name'

PY> Foo.age
AttributeError: type object 'Foo' has no attribute 'age'

# END INTERACTIVE SESSION


Of course, "name" and "age" would be more appropriate when
defined as instance variables, since both are attributes
specific to each person. A class level variable should only
be used for an attribute that is shared by *ALL* instances
of the class, and one that is *NOT* specific to any one of
them.

For instance, something highly general like keeping a tally
of the total number of "Persons" created, or the total
number of persons with red hair, or with green eyes. These
are the more generalized attributes of *ALL* persons, that
are not specific to any *ONE* person.

By offering example code that attempts to initialize class
level variables in the constructor, you have exposed yourself
as not understanding what a class level variable *IS*. Mark, we
*DON'T* initialize class level variables, no, we assign them
to the "class object". Class level variables are intended to
be used as "shared state" between multiple instances, not
"initialized" by each instance.

But don't feel bad. Most folks would be surprised at the
high percentage of "seasoned programmers" who do not
understand the difference between class level, and instance
level variables. I've have personally witnessed someone say
aloud: "Class variables are useless, always use instance
variables instead".

Oh my! o_O

There are two types of variables you can create relative to
a class: instance level variables, and class level
variables. In python, both of them can be read and written at
will, however, creating them and accessing them is slightly
different.

PS: Ignorance of the unknown produces fear, and fear can
produce unwarranted hatred. I have suspected for many years
that those in the Python community who are constantly bad-
mouthing OOP, are displaying an emotional reaction rooted in
the psychological distress of ignorance and fear, and your 
posting here has provided evidence of that distress.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyhon 2.x or 3.x, which is faster?

[Michael Torrie]

On 03/11/2016 03:24 PM, BartC wrote:
> On 11/03/2016 21:59, Mark Lawrence wrote:
>> On 11/03/2016 18:57, BartC wrote:
> 
>> def test():
>>  s=""
>>  for i in range(1000):
>>  s+="*"
>>  print (len(s))
>>
>> test()
> 
>> The minor snag that you might like to correct with your microbenchmark,
>> which any experienced Python programmer knows, is that you *NEVER, EVER*
>> create strings like this.
> 
> Why not? Chris said his version runs much faster (even allowing for 
> different machines), and might have a special optimisation for it.
> 
> And I think it can be optimised if, for example, there are no other 
> references to the string that s refers to.
> 
> So what's wrong with trying to fix it rather that using a workaround?

The act of "fixing" it, as you say, would change the semantics of the
language in a fundamental and major way.  Strings by definition are
immutable in Python.  If you need otherwise, there are other better
tools such as a buffer object of some kind, or StringIO which makes
file-like objects you can read and write to randomly.

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

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[BartC]

On 11/03/2016 21:36, Chris Angelico wrote:

On Sat, Mar 12, 2016 at 5:57 AM, BartC  wrote:



Functions are dynamic. That is, you don't know the F in F() is actually a 
function, even if it was defined a few lines previously, because it could have 
been rebound to something else. That means a runtime check to ensure that it is 
one.



All of these are really one thing: When you compile some code, you
don't know whether F() is still going to be the same object when you
run it. FAT Python is intended to pick this up;


That's an interesting project. And they seem to understand the problems.

 it recognizes

constants, and can then perform all the other optimizations you
describe (since functions are themselves immutable, all you need is an
identity check on the function object itself, and everything else you
describe can be done safely).


You mean the compiler assumes it's a particular function, but adds a 
runtime check? (Perhaps by generating two call sequences, one fast, and 
selecting the path at runtime.)



* Variables are dynamic. So you can't for example declare (with a new const 
feature)

'const rows=50'


Definitely agree with this. Having a way to declare that a name is
"truly constant" would be extremely handy; there currently isn't a
way, and I'm not sure whether FAT Python is looking into this or not.
I think it's more focusing on the situation where something simply has
never been rebound, which is probably the better optimization; but
sometimes it'd be nice to be able to assert that something *will not*
be rebound, to help with self-documenting code. (Note that "constant"
implies both "never rebound" and "immutable".


The 'const' prefix here is intended to define a named constant (a 
numeric literal with a convenient alias) rather than some 'read-only 
attribute for a conventional variable.


But introducing that into Python would be a can of worms. (A named 
constant needs a compile-time expression on the right-hand-side. The 
compiler needs to be able to see named constants which are in an 
imported module, and which are accessed via attributes, and so on.)



  * Without a way of defining compile-time constants, very useful language 
features such as 'switch' are not practical.


Maybe, but I honestly don't miss 'switch' all that often - and when I
do, it's usually because I want a range. Consider this
semi-hypothetical Pike code:

switch (key)
{
 case 'A'..'Z': case 'a'..'z': return "Letter";
 case 0xFF00..0x: return "Special key";
 case '.': case ',': case '!': return "Punctuation";
 default: return "Other";
}

With a small number of cases, this wouldn't be too bad in if/elif
form; but as it gets bigger, the value of a switch block becomes
evident. The normal advice in Python is "use a dispatch dictionary",
but that would be impractical here. So this would end up being a
massive if/elif tree, because there's just no better way to do this.


Your example doesn't really need a switch: a range check and a 
predefined list or tuple which maps 0 to 255 to a certain string.


Otherwise a list of functions indexed by the switch key would generally 
do, and might be faster than an if-elsif chain. But there's some untidy 
setup code and the rest would be spread out across various functions.


A proper 'switch' statement takes care of all that setup code, and keeps 
the blocks of code localised. And selection of the correct bit of code 
is very fast, as it's done inside the interpreter with a single 
byte-code (well, load and switch).


(See yet another microbenchmark below.)


* Python 3 has decided to have a single 'long' type for integers, instead of 
separate int (32 or 64-bit) and long types. This gives a noticeable slow-down 
in programs executing lots of integer code, compared with Python 2.



That said, though: I suspect the reason nobody's gone and done this is
not that it wouldn't be any benefit, but that applications doing a lot
of integer code are usually going to see more benefit from Numpy,
Cython, or PyPy,


You'd be surprised how much any kind of program relies on adhoc integer 
operations. It doesn't need to work with large int arrays for them to be 
important. (Look at the benchmark below: the inner loop is nearly all 
integer ops.)



For anything other than individual characters, this is likely to
perform better. However, I was unable to see this, because *CPython
does optimize string appends*.


I guess mine doesn't! (I don't think my PC is 30 times slower than yours.)



'Switch' testing benchmark. The little program show below reads a text 
file (I used the entire CPython C sources, 6MB), and counts the number 
of characters of each category in upper, lower, digit and other.


(Note there are other ways to approach this task, but a proper 'lexer' 
usually does more than count. 'Switch' then becomes invaluable.)


On my machine, I got 2.8 - 3.6 seconds (PyPy 0.4 seconds).

I tried my bytecode language, with the same if-els

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Chris Angelico]

On Sat, Mar 12, 2016 at 12:16 PM, BartC  wrote:
> On 11/03/2016 21:36, Chris Angelico wrote:
>>
>> constants, and can then perform all the other optimizations you
>> describe (since functions are themselves immutable, all you need is an
>> identity check on the function object itself, and everything else you
>> describe can be done safely).
>
>
> You mean the compiler assumes it's a particular function, but adds a runtime
> check? (Perhaps by generating two call sequences, one fast, and selecting
> the path at runtime.)

Exactly. Fast path, slow path. The cost of checking is, in many cases,
less than the advantage gained.

>>> * Variables are dynamic. So you can't for example declare (with a new
>>> const feature)
>
> 'const rows=50'
>
>> Definitely agree with this. Having a way to declare that a name is
>> "truly constant" would be extremely handy; there currently isn't a
>> way, and I'm not sure whether FAT Python is looking into this or not.
>> I think it's more focusing on the situation where something simply has
>> never been rebound, which is probably the better optimization; but
>> sometimes it'd be nice to be able to assert that something *will not*
>> be rebound, to help with self-documenting code. (Note that "constant"
>> implies both "never rebound" and "immutable".
>
>
> The 'const' prefix here is intended to define a named constant (a numeric
> literal with a convenient alias) rather than some 'read-only attribute for a
> conventional variable.
>
> But introducing that into Python would be a can of worms. (A named constant
> needs a compile-time expression on the right-hand-side. The compiler needs
> to be able to see named constants which are in an imported module, and which
> are accessed via attributes, and so on.)

Not sure about that. Consider:

MAX_SIZE = 1<<16
def some_func(blah):
data = some_file.read(MAX_SIZE)

Currently, this disassembles to show that MAX_SIZE is being fetched
with LOAD_GLOBAL. If, instead, it were LOAD_CONST, this would mean
that rebinding MAX_SIZE after function definition would fail; but it
would run faster. That's the advantage of a "declared constant", even
without it being any sort of compile-time constant. As long as it can
be finalized before the function is defined, it can be called
constant.

>> Maybe, but I honestly don't miss 'switch' all that often - and when I
>> do, it's usually because I want a range. Consider this
>> semi-hypothetical Pike code:
>>
>> switch (key)
>> {
>>  case 'A'..'Z': case 'a'..'z': return "Letter";
>>  case 0xFF00..0x: return "Special key";
>>  case '.': case ',': case '!': return "Punctuation";
>>  default: return "Other";
>> }
>>
>> With a small number of cases, this wouldn't be too bad in if/elif
>> form; but as it gets bigger, the value of a switch block becomes
>> evident. The normal advice in Python is "use a dispatch dictionary",
>> but that would be impractical here. So this would end up being a
>> massive if/elif tree, because there's just no better way to do this.
>
>
> Your example doesn't really need a switch: a range check and a predefined
> list or tuple which maps 0 to 255 to a certain string.

This is not bounded to 0..255. Even if it were, I don't want to have
to represent this in my code with anything other than a range. (If
it's represented internally with a lookup table, that's fine, as long
as it's invisible to my code.) Plus, the value of a switch block comes
from arbitrary code, not toy examples that return constant strings; if
the only uses of switch were like this, sure, we could all use
dictionaries easily.

>> That said, though: I suspect the reason nobody's gone and done this is
>> not that it wouldn't be any benefit, but that applications doing a lot
>> of integer code are usually going to see more benefit from Numpy,
>> Cython, or PyPy,
>
> You'd be surprised how much any kind of program relies on adhoc integer
> operations. It doesn't need to work with large int arrays for them to be
> important. (Look at the benchmark below: the inner loop is nearly all
> integer ops.)

Sure, but in real-world code, there are other considerations than just
integer performance. If someone waves a magic wand and improves
machine-word integer performance, great, but there are other calls on
core dev time.

Since it can be done without any externally-visible changes, it's a
"safe optimization" that any Python implementation would be free to
attempt.

> 'Switch' testing benchmark. The little program show below reads a text file
> (I used the entire CPython C sources, 6MB), and counts the number of
> characters of each category in upper, lower, digit and other.
>
> (Note there are other ways to approach this task, but a proper 'lexer'
> usually does more than count. 'Switch' then becomes invaluable.)

Are you assuming that the files are entirely ASCII? (They're not.) Or
are you simply declaring that all non-ASCII characters count as
"other"?

Once again, you cannot ignore Unicode and pretend that 

Re: Encapsulation in Python

[Rick Johnson]

On Friday, March 11, 2016 at 9:48:22 AM UTC-6, Ian wrote:
> On Thu, Mar 10, 2016 at 5:45 PM, Rick Johnson
> The honorable Rick Johnson wrote:
> > Many times, i would have preferred to define my module space
> > across multiple files, multiple files that could share state
> > without resorting to the yoga-style "import contortions",
> > and/or the dreaded "circular import nightmares" that plague
> > our community today.
>
> Sounds to me like you're blaming Python for your own poor design.
> Possible solutions:
>
> 1) Don't do that. If your module is too big for one file, then it's
> likely poorly organized and doesn't all belong in one module anyway.

Apparently you've missed the many heated arguments between
Chris Angelico and myself concerning the size of source
files. I have *ALWAYS* taken the position that source files
should be kept as small as possible, but that position is
more relevant in Python, were modules are defined by a
single source file. I don't take the Java position that a
module can only contain one class, but i like to keep the
number of classes (IN MY SOURCE FILES) small.

At run-time, i don't care how large a "module namespace" may
be. Sometimes a module namespace will be small, with only a
few exposed symbols, but sometimes, a module namespace will
expose thousands of symbols. The size of a "run-time module"
is irrelevant in most languages, but here in Python, were
module namespace is defined by the contents of *ONE SINGLE
SOURCE FILE*, the whole ballgame is changed. If i need to
create a module that contains many exposed symbols in
Python, i'm forced to do one of the following:

  (1) Write all my code in a single *GIGANTIC* file...

or

  (2) Create one file that will be the "mother-ship module",
  and N files that will be the "satellite modules", and from
  inside the mother-ship, import all the symbols from all
  the satellites. Ha, but in reality, it's not that simple,
  because state does not "magically" travel between modules!

##
# foo.py #
##
FOO_SHARED_STATE = "foo"
import _fooSatilite1
_fooSatilite1.FOO_SHARED_STATE = FOO_SHARED_STATE
from _fooSatilite1 import *
import _fooSatilite2
_fooSatilite2.FOO_SHARED_STATE = FOO_SHARED_STATE
from _fooSatilite2 import *
print 'This is the mother-ship called foo'
...


# _fooSatilite1.py #

from _fooConstants import *
print 'This is foo-fighter1, reporting for duty'
print FOO_SHARED_STATE
...


# _fooSatilite2.py #

from _fooConstants import *
print 'This is foo-fighter2, reporting for duty'
print FOO_SHARED_STATE
...

But i find both to be absurd. Writing all code in a single
file might be fine for a toy module that contains a handful
of functions or classes or vars, but once we start creating 
anything in the "professional size range", it will become 
an "editing nightmare" of epic proportions!

But option two is no better, because once we cut and paste
portions of the code into satellite files, we lose the
ability to "easily share state". Then we're forced to start
"hacking at the weeds" with import contortions and monkey
patches, all the while, fearing the dreaded circular import.


NO, THIS IS INSANITY!  WHAT WE NEED IS AN OPTION 3!

 (3) Allow a programmer to define module space at will

##
# foo.py #
##
module foo
FOO_SHARED_STATE = "foo"
print 'This is the mother-ship called foo'
...


# _fooSatilite1.py #

module foo
print 'This is foo-fighter1, reporting for duty'
print FOO_SHARED_STATE # NO MP REQUIRED!
...


# _fooSatilite2.py #

module foo
print 'This is foo-fighter2, reporting for duty'
print FOO_SHARED_STATE # NO MP REQUIRED!
...

No need for import contortions, no need for monkey patching,
but most importantly, no need for professional programmers
to feel as though they are penchant little children, who
need their "module diapers" wrapped for them by mommy
Python, who, after popping one too many "mother's little
helpers", has a nasty habit of wrapping our diapers too damn
tight -- what a drag, it is, getting old...

> 2) Clearly define which module is to be imported first. Then follow
> it. When module b is imported, it should import module a. When module
> a is imported, it *shouldn't* import module b until it's defined all
> of its own members first. If module a depends on anything from module
> b at import time, then refactor so it doesn't. This doesn't require
> "contortions".

That sounds simple in theory, but it breaks down quickly
when you create "professional sized programs"

> 3) Just put all your damn shared state in a class. There's nothing
> stopping you from spreading out your class method definitions over
> multiple files if you real

Re: Encapsulation in Python

[Rick Johnson]

On Friday, March 11, 2016 at 9:48:22 AM UTC-6, Ian wrote:
> On Thu, Mar 10, 2016 at 5:45 PM, Rick Johnson wrote:
> > Many times, i would have preferred to define my module space
> > across multiple files, multiple files that could share state
> > without resorting to the yoga-style "import contortions",
> > and/or the dreaded "circular import nightmares" that plague
> > our community today.
>
> Sounds to me like you're blaming Python for your own poor design.
> Possible solutions:
>
> 1) Don't do that. If your module is too big for one file, then it's
> likely poorly organized and doesn't all belong in one module anyway.

Apparently you've missed the many heated arguments between
Chris Angelico and myself concerning the size of source
files. I have *ALWAYS* taken the position that source files
should be kept as small as possible, but that position is
more relevant in Python, were modules are defined by a
single source file. I don't take the Java position that a
module can only contain one class, but i like to keep the
number of classes (IN MY SOURCE FILES) small.

At run-time, i don't care how large a "module namespace" may
be. Sometimes a module namespace will be small, with only a
few exposed symbols, but sometimes, a module namespace will
expose thousands of symbols. The size of a "run-time module"
is irrelevant in most languages, but here in Python, were
module namespace is defined by the contents of *ONE SINGLE
SOURCE FILE*, the whole ballgame is changed. If i need to
create a module that contains many exposed symbols in
Python, i'm forced to do one of the following:

  (1) Write all my code in a single *GIGANTIC* file...

or

  (2) Create one file that will be the "mother-ship module",
  and N files that will be the "satellite modules", and from
  inside the mother-ship, import all the symbols from all
  the satellites. Ha, but in reality, it's not that simple,
  because state does not "magically" travel between modules!

##
# foo.py #
##
FOO_SHARED_STATE = "foo"
import _fooSatilite1
_fooSatilite1.FOO_SHARED_STATE = FOO_SHARED_STATE
from _fooSatilite1 import *
import _fooSatilite2
_fooSatilite2.FOO_SHARED_STATE = FOO_SHARED_STATE
from _fooSatilite2 import *
print 'This is the mother-ship called foo'
...


# _fooSatilite1.py #

from _fooConstants import *
print 'This is foo-fighter1, reporting for duty'
print FOO_SHARED_STATE
...


# _fooSatilite2.py #

from _fooConstants import *
print 'This is foo-fighter2, reporting for duty'
print FOO_SHARED_STATE
...

But i find both to be absurd. Writing all code in a single
file might be fine for a toy module that contains a handful
of functions or classes or vars, but once we start creating 
anything in the "professional size range", it will become 
an "editing nightmare" of epic proportions!

But option two is no better, because once we cut and paste
portions of the code into satellite files, we lose the
ability to "easily share state". Then we're forced to start
"hacking at the weeds" with import contortions and monkey
patches, all the while, fearing the dreaded circular import.


NO, THIS IS INSANITY!  WHAT WE NEED IS AN OPTION 3!

 (3) Allow a programmer to define module space at will

##
# foo.py #
##
module foo
FOO_SHARED_STATE = "foo"
print 'This is the mother-ship called foo'
...


# _fooSatilite1.py #

module foo
print 'This is foo-fighter1, reporting for duty'
print FOO_SHARED_STATE # NO MP REQUIRED!
...


# _fooSatilite2.py #

module foo
print 'This is foo-fighter2, reporting for duty'
print FOO_SHARED_STATE # NO MP REQUIRED!
...

No need for import contortions, no need for monkey patching,
but most importantly, no need for professional programmers
to feel as though they are penchant little children, who
need their "module diapers" wrapped for them by mommy
Python, who, after popping one too many "mother's little
helpers", has a nasty habit of wrapping our diapers too damn
tight -- it's high time for these py-babies to go commando,
baby!

> 2) Clearly define which module is to be imported first. Then follow
> it. When module b is imported, it should import module a. When module
> a is imported, it *shouldn't* import module b until it's defined all
> of its own members first. If module a depends on anything from module
> b at import time, then refactor so it doesn't. This doesn't require
> "contortions".

That sounds simple in theory, but it breaks down quickly
when you create "professional sized programs"

> 3) Just put all your damn shared state in a class. There's nothing
> stopping you from spreading out your class method definitions over
> multiple files if you really want

Psycopg2 to create a record using a FK

[Aaron Christensen]

Hello,

I am running the following versions of software:

Python 3.5
psycopg2==2.6.1
Postgres 9.4.5

I have 2 tables.  Table User has UserId (serial PK), LastName, FirstName,
Gender, DateOfBirth, and DateEnrolled.  Table UserProfile has UserProfileId
(serial, PK), UserId (FK), DateEntered, FaveNumber, and Activity.  There is
a one-to-many relationship.

The following PostgreSQL works and ultimately creates a record in
UserProfile with an associated UserId (FK).

\set last_name '''Sara'''
\set first_name '''Jackson'''
\set gender '''F'''
\set dob '''1941-1-12'''
\set fave_number '''3'''
\set activity '''volleyball'''


WITH ins_user AS (
INSERT INTO User
(LastName, FirstName, Gender, DateOfBirth, DateEnrolled)
VALUES (:last_name, :first_name, :gender, :dob, now())
RETURNING UserId)
INSERT INTO UserProfile
(UserId, DateEntered, FaveNumber, Activity)
VALUES ( (SELECT UserId FROM ins_user), now(), :fave_number :activity);

How can I build a psycopg2 cur.execute query that will accomplish the above
PostgreSQL?  I've read documentation but can't seem to get a handle on how
I should structure this command.

My starting point is:

cur.execute( \
"""INSERT INTO User \
(LastName, FirstName, Gender, DateOfBirth, DateEnrolled) \
VALUES (%s, %s, %s, %s, %s) RETURNING UserId;""", \
(last_name, first_name, gender, date_of_birth, now(), ??...??)


Also, I have a second question.  Is it possible to extract that value
derived from "RETURNING UserId" so that it can be used in a later query?

Thank you for your time!
Aaron
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

[Rustom Mody]

On Saturday, March 12, 2016 at 7:50:43 AM UTC+5:30, Chris Angelico wrote:
> On Sat, Mar 12, 2016 at 12:16 PM, BartC  wrote:
> > You'd be surprised how much any kind of program relies on adhoc integer
> > operations. It doesn't need to work with large int arrays for them to be
> > important. (Look at the benchmark below: the inner loop is nearly all
> > integer ops.)
> 
> Sure, but in real-world code, there are other considerations than just
> integer performance. If someone waves a magic wand and improves
> machine-word integer performance, great, but there are other calls on
> core dev time.

I guess that BartC (or is it Bartc?) is describing something that is a 
commonplace in compiler world but not so well known elsewhere, viz.
a simple operation like an array/attribute-access etc, which from a HLL pov
may have no 'operations' at all may emit a slew of integer operations when
compiled.  Which is not so surprising if you consider that apart from
control-flow there is nothing going on in a CPU beside arithmetic; there
is no datatype beside integers of various sizes and (un)signed combos.
-- 
https://mail.python.org/mailman/listinfo/python-list

Descriptors vs Property

[Veek. M]

A property uses the @property decorator and has @foo.setter 
@foo.deleter.

A descriptor follows the descriptor protocol and implements the __get__ 
__set__ __delete__ methods.

But they both do essentially the same thing, allow us to do:
foo = 10
del foo
x = foo

So why do we have two ways of doing this?


Also,
#
class TypedProperty(object):
def __init__(self,name,type,default=None):
self.name = "_" + name
self.type = type 
self.default = default if default else type()

def __get__(self,instance,cls):
return getattr(instance,self.name,self.default)

def __set__(self,instance,value):
if not isinstance(value,self.type):
raise TypeError("Must be a %s" % self.type)
setattr(instance,self.name,value)

def __delete__(self,instance):
raise AttributeError("Can't delete attribute")

class Foo(object):
name = TypedProperty("name",str)
num  = TypedProperty("num",int,42)

In this example, the class TypedProperty defines a descriptor where type 
checking is
performed when the attribute is assigned and an error is produced if an 
attempt is made
to delete the attribute. For example:

f = Foo()
a = f.name   # Implicitly calls Foo.name.__get__(f,Foo)
f.name = "Guido" # Calls Foo.name.__set__(f,"Guido")
del f.name   # Calls Foo.name.__delete__(f)
##

I didn't follow this. Foo is a composition of TypedProperty.
You've got a 'Foo' type with two attributes 'name' and 'num'.
When you do f.name you are actually doing:
f.name.__get__(self, instance, cls)
What the heck??

I didn't follow this example at all.. What is he doing in there?
Also, what's this bit:
self.default = default if default else type()

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

Re: Pyhon 2.x or 3.x, which is faster?

[Steven D'Aprano]

On Sat, 12 Mar 2016 12:10 pm, Dennis Lee Bieber wrote:

> On Fri, 11 Mar 2016 22:24:45 +, BartC  declaimed the
> following:
> 
>>On 11/03/2016 21:59, Mark Lawrence wrote:
>>> On 11/03/2016 18:57, BartC wrote:
>>
>>> def test():
>>>  s=""
>>>  for i in range(1000):
>>>  s+="*"
>>>  print (len(s))
>>>
>>> test()
>>
>>> The minor snag that you might like to correct with your microbenchmark,
>>> which any experienced Python programmer knows, is that you *NEVER, EVER*
>>> create strings like this.
>>
>>Why not? Chris said his version runs much faster (even allowing for
>>different machines), and might have a special optimisation for it.
>>
> 
> Everytime that += is executed, Python has to allocate a new chunk of
> memory equal (minimum -- it may chunk larger) to the combined length of
> "s" and "*", COPY the bytes/characters from "s" into the new memory chunk,
> copy the "*" into the end of the new memory chunk, bind the name "s" to
> the new chunk, and likely deallocate the old memory chunk that used to be
> bound to "s".

Sometimes.

What you say is true in Jython and IronPython. And it was always true in
CPython until version 2.3. And it is sometimes true in CPython even today.

But since Python 2.3, CPython is smart enough to recognise when a string has
only one reference to it, and, *if possible*, resize it in place. This
optimization seems to work well under Linux, but unfortunately due to the
vagaries of how memory is managed by the OS, it seems to often fail under
Windows, so Python will fall back to the slow copy-and-append
implementation.



[...]
> The common recommendation is to accumulate the substrings into a LIST
> structure (while the list will undergo resizing, that is done at a fairly
> well-understood rate, and only requires copying of references to the
> substrings, not the strings themselves). At the end, one invokes .join()
> on the list. .join() can scan the list elements summing the lengths of the
> substrings, allocate ONCE the memory to hold the result, and only then
> copy the substrings into the result string.

This remains the best advice for assembling strings from a large number of
small pieces.




-- 
Steven

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

Re: Descriptors vs Property

[Chris Angelico]

On Sat, Mar 12, 2016 at 4:59 PM, Veek. M  wrote:
> A property uses the @property decorator and has @foo.setter
> @foo.deleter.
>
> A descriptor follows the descriptor protocol and implements the __get__
> __set__ __delete__ methods.
>
> But they both do essentially the same thing, allow us to do:
> foo = 10
> del foo
> x = foo
>
> So why do we have two ways of doing this?

The descriptor protocol is what powers the @property decorator. It's
like asking why we have both lists and sequences; the sequence
protocol is how you interact with lists.

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

Re: Descriptors vs Property

[Ian Kelly]

On Fri, Mar 11, 2016 at 10:59 PM, Veek. M  wrote:
> A property uses the @property decorator and has @foo.setter
> @foo.deleter.
>
> A descriptor follows the descriptor protocol and implements the __get__
> __set__ __delete__ methods.
>
> But they both do essentially the same thing, allow us to do:
> foo = 10
> del foo
> x = foo
>
> So why do we have two ways of doing this?

Properties *are* descriptors. Properties just provide a more natural
syntax for a very common case.

> Also,
> #
> class TypedProperty(object):
> def __init__(self,name,type,default=None):
> self.name = "_" + name
> self.type = type
> self.default = default if default else type()
>
> def __get__(self,instance,cls):
> return getattr(instance,self.name,self.default)
>
> def __set__(self,instance,value):
> if not isinstance(value,self.type):
> raise TypeError("Must be a %s" % self.type)
> setattr(instance,self.name,value)
>
> def __delete__(self,instance):
> raise AttributeError("Can't delete attribute")
>
> class Foo(object):
> name = TypedProperty("name",str)
> num  = TypedProperty("num",int,42)
>
> In this example, the class TypedProperty defines a descriptor where type
> checking is
> performed when the attribute is assigned and an error is produced if an
> attempt is made
> to delete the attribute. For example:
>
> f = Foo()
> a = f.name   # Implicitly calls Foo.name.__get__(f,Foo)
> f.name = "Guido" # Calls Foo.name.__set__(f,"Guido")
> del f.name   # Calls Foo.name.__delete__(f)
> ##
>
> I didn't follow this. Foo is a composition of TypedProperty.
> You've got a 'Foo' type with two attributes 'name' and 'num'.
> When you do f.name you are actually doing:
> f.name.__get__(self, instance, cls)

More accurately, you're doing
f.__class__.__dict__['name'].__get__(self, instance, cls). But yes,
this is how the descriptor protocol works.

> What the heck??
>
> I didn't follow this example at all.. What is he doing in there?
> Also, what's this bit:
> self.default = default if default else type()

If the default parameter has a truthy value, it gets set to
self.default. Otherwise, the type parameter is called with no
arguments, and the resulting instance is used as self.default instead.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Descriptors vs Property

[Veek. M]

Veek. M wrote:

> A property uses the @property decorator and has @foo.setter
> @foo.deleter.
> 
> A descriptor follows the descriptor protocol and implements the
> __get__ __set__ __delete__ methods.
> 
> But they both do essentially the same thing, allow us to do:
> foo = 10
> del foo
> x = foo
> 
> So why do we have two ways of doing this?
> 
> 
> Also,
> #
> class TypedProperty(object):
> def __init__(self,name,type,default=None):
> self.name = "_" + name
> self.type = type
> self.default = default if default else type()
> 
> def __get__(self,instance,cls):
> return getattr(instance,self.name,self.default)
> 
> def __set__(self,instance,value):
> if not isinstance(value,self.type):
> raise TypeError("Must be a %s" % self.type)
> setattr(instance,self.name,value)
> 
> def __delete__(self,instance):
> raise AttributeError("Can't delete attribute")
> 
> class Foo(object):
> name = TypedProperty("name",str)
> num  = TypedProperty("num",int,42)
> 
> In this example, the class TypedProperty defines a descriptor where
> type checking is
> performed when the attribute is assigned and an error is produced if
> an attempt is made
> to delete the attribute. For example:
> 
> f = Foo()
> a = f.name   # Implicitly calls Foo.name.__get__(f,Foo)
> f.name = "Guido" # Calls Foo.name.__set__(f,"Guido")
> del f.name   # Calls Foo.name.__delete__(f)
> ##
> 
> I didn't follow this. Foo is a composition of TypedProperty.
> You've got a 'Foo' type with two attributes 'name' and 'num'.
> When you do f.name you are actually doing:

> f.name.__get__(self, instance, cls)
> What the heck??
As in, why is he passing instance, cls and who is populating those vars?
When you do f.name you just have self to pass into 
name.__whatever__(self)
I haven't read the descriptor protocol as yet. 


> self.default = default if default else type()
I don't understand how he's using type() like that or what it returns. 
Is it None? Why would type() return None when one can use that directly.


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

Re: Descriptors vs Property

[Veek. M]

Ian Kelly wrote:

> On Fri, Mar 11, 2016 at 10:59 PM, Veek. M  wrote:
>> A property uses the @property decorator and has @foo.setter
>> @foo.deleter.
>>
>> A descriptor follows the descriptor protocol and implements the
>> __get__ __set__ __delete__ methods.
>>
>> But they both do essentially the same thing, allow us to do:
>> foo = 10
>> del foo
>> x = foo
>>
>> So why do we have two ways of doing this?
> 
> Properties *are* descriptors. Properties just provide a more natural
> syntax for a very common case.
> 
>> Also,
>> #
>> class TypedProperty(object):
>> def __init__(self,name,type,default=None):
>> self.name = "_" + name
>> self.type = type
>> self.default = default if default else type()
>>
>> def __get__(self,instance,cls):
>> return getattr(instance,self.name,self.default)
>>
>> def __set__(self,instance,value):
>> if not isinstance(value,self.type):
>> raise TypeError("Must be a %s" % self.type)
>> setattr(instance,self.name,value)
>>
>> def __delete__(self,instance):
>> raise AttributeError("Can't delete attribute")
>>
>> class Foo(object):
>> name = TypedProperty("name",str)
>> num  = TypedProperty("num",int,42)
>>
>> In this example, the class TypedProperty defines a descriptor where
>> type checking is
>> performed when the attribute is assigned and an error is produced if
>> an attempt is made
>> to delete the attribute. For example:
>>
>> f = Foo()
>> a = f.name   # Implicitly calls Foo.name.__get__(f,Foo)
>> f.name = "Guido" # Calls Foo.name.__set__(f,"Guido")
>> del f.name   # Calls Foo.name.__delete__(f)
>> ##
>>
>> I didn't follow this. Foo is a composition of TypedProperty.
>> You've got a 'Foo' type with two attributes 'name' and 'num'.
>> When you do f.name you are actually doing:
>> f.name.__get__(self, instance, cls)
> 
> More accurately, you're doing
> f.__class__.__dict__['name'].__get__(self, instance, cls). But yes,
> this is how the descriptor protocol works.
thanks okay i'll read that and get back
> 
>> What the heck??
>>
>> I didn't follow this example at all.. What is he doing in there?
>> Also, what's this bit:
>> self.default = default if default else type()
> 
> If the default parameter has a truthy value, it gets set to
> self.default. Otherwise, the type parameter is called with no
> arguments, and the resulting instance is used as self.default instead.
 
But type() just gives me:
TypeError: type() takes 1 or 3 arguments
on py2,3
-- 
https://mail.python.org/mailman/listinfo/python-list