Re: Question re: objects and square grids

[Larry Hudson]

On 05/15/2013 05:53 PM, Andrew Bradley wrote:



I apologize if these questions are too rudimentary--I am trying to wrap my head 
around how this
language works in a more general sense so I can start applying it to things.
-Andrew


Check out the book "Making Games with Python & Pygame" at 
http://inventwithpython.com/pygame/
It's a book you can buy or you can download the pdf or e-reader versions for 
free.

Also on the same site, "Invent Your Own Computer Games with Python"

Both are pretty good introductions to Python programming, "Invent..." is for non-graphic games, 
and may be the better to start with.  Don't try to get too advanced too fast -- you'll only get 
frustrated and discouraged.  But definitely do keep at it -- it's well worth the effort.


 -=- Larry -=-

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

Re: Python 2.7.x - problem with obejct.__init__() not accepting *args and **kwargs

[Ian Kelly]

On Wed, May 15, 2013 at 8:06 PM, Steven D'Aprano
 wrote:
> On Wed, 15 May 2013 13:16:09 +0100, Oscar Benjamin wrote:
>
>
>> I don't generally use super()
>
> Then you should, especially in Python 3.
>
> If you're not using super in single-inheritance classes, then you're
> merely making your own code harder to read and write, and unnecessarily
> difficult for others to use with multiple-inheritance.
>
> If you're not using super in multiple-inheritance[1] classes, then your
> code is probably buggy.
>
> There really is no good reason to avoid super in Python 3.

The Python 3 syntactic sugar is the primary reason that I've finally
started using super in single-inheritance classes.  The magicalness of
it still disturbs me a bit, though.

>>> class A:
... def __str__(self):
... return super().__str__()
...
>>> class B:
... __str__ = A.__str__
...
>>> A().__str__
>
>>> str(A())
'<__main__.A object at 0x0289E270>'
>>> B().__str__
>

The transplanted __str__ method is considered a method of B by Python...

>>> str(B())
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in __str__
TypeError: super(type, obj): obj must be an instance or subtype of type

But you can't use it because the super() call is irrevocably tied to
class A.  :-P

Of course the same is true with the syntax "super(A, self)", but at
least with that syntax it is clear that the method is explicitly
referencing class A, and so should not be expected to work correctly
in class B.  By contrast the syntax "super()" looks misleadingly
generic.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python for philosophers

[Andrew Berg]

Tim Daneliuk wrote:
> All You People are making this way too hard.  To understand how
> questions like the OPs ought be resolved, please read:
> 
> http://pvspade.com/Sartre/cookbook.html

On this list, I would expect a Sartre reference to be something like this:
https://www.youtube.com/watch?v=crIJvcWkVcs

-- 
CPython 3.3.1 | Windows NT 6.2.9200 / FreeBSD 9.1
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Determine actually given command line arguments

[Jussi Piitulainen]

Henry Leyh writes:

> But now I would also like to be able to _write_ such a config file
> FILE that can be read in a later run.  And FILE should contain only
> those arguments that were given on the command line.
> 
> Say, I tell argparse to look for arguments -s|--sopt STRING,
> -i|--iopt INT, -b|--bopt [BOOL], -C CONFFILE.  Then 'prog -s bla -i
> 42 -C cfile' should produce a confparser compatible cfile which
> contains
> 
>[my_options]
>sopt = blah
>iopt = 42
> 
> and not 'bopt = False' (if False was the program's default for
> bopt).

Could you instead write those options that differ from the defaults?
You could parse an actual command line and an empty command line, and
work out the difference.

So 'prog -i 3' would not cause 'iopt = 3' to be written if 3 is the
default for iopt, but would that be a problem?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating multi-part emails

[dieter]

Steven D'Aprano  writes:

> I wish to generate some test data for a program that deals with emails. I 
> need something that can produce multi-part emails, including "broken" 
> emails that violate email standards, especially when it comes to Unicode.

I would start producing legal messages (e.g. with the "email"
package) and then put in common standard violations.

I am using the XEmacs "vm" email package and it has
difficulties with the quoting of non-ascii characters
in header lines (it performes the quoting based on non-ascii
character sequences rather than on words, as it should).


Maybe, there is an email message catalog around for the test
of email servers/clients. I would check for this in corresponding
open source projects.

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

Re: Determine actually given command line arguments

[Henry Leyh]

On 15.05.2013 17:29, Roy Smith wrote:

In article ,
Henry Leyh   wrote:

On 15.05.2013 14:24, Roy Smith wrote:

In article ,
   Henry Leyh  wrote:


Is there a simple way to determine which
command line arguments were actually given on the commandline, i.e. does
argparse.ArgumentParser() know which of its namespace members were
actually hit during parse_args().


I think what you're looking for is sys.argv:

$ cat argv.py
import sys
print sys.argv

$ python argv.py foo bar
['argv.py', 'foo', 'bar']


Thanks, but as I wrote in my first posting I am aware of sys.argv and
was hoping to _avoid_ using it because I'd then have to kind of
re-implement a lot of the stuff already there in argparse, e.g. parsing
sys.argv for short/long options, flag/parameter options etc.


Sorry, I missed that.

I'm not clear on exactly what you're trying to do.  You say:


Now I would also like the program to be able to _write_ a
configparser config file that contains only the parameters actually
given on the commandline.


I'm guessing what you're trying to do is parse the command line first,
then anything that was set there can get overridden by a value in the
config file?  That seems backwards.  Usually, the order is:

1) built-in default
2) config file (possibly a system config file, then a per-user one)
3) environment variable
4) command-line argument

It sounds like you're doing it in the reverse order -- allowing the
config file to override the command line.


No.  The program reads a general config file in $HOME, something like 
~/.programrc; then parses the command like for '-c FILE' and, if FILE is 
present reads it; then parses the command line remains for more 
arguments which overwrite everything previously set.  (For the record, 
this split parsing is done with two argparse parsers.  The first parses 
for '-c FILE' with parse_known_args().  If there is a FILE, its contents 
is used as defaults for a second parser (using set_options()) which then 
parses the remains that were returned by the first parser's 
parse_known_args().)


But now I would also like to be able to _write_ such a config file FILE 
that can be read in a later run.  And FILE should contain only those 
arguments that were given on the command line.


Say, I tell argparse to look for arguments -s|--sopt STRING, -i|--iopt 
INT, -b|--bopt [BOOL], -C CONFFILE.  Then 'prog -s bla -i 42 -C cfile' 
should produce a confparser compatible cfile which contains


  [my_options]
  sopt = blah
  iopt = 42

and not 'bopt = False' (if False was the program's default for bopt).

Regards,
Henry

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

Generating multi-part emails

[Steven D'Aprano]

I wish to generate some test data for a program that deals with emails. I 
need something that can produce multi-part emails, including "broken" 
emails that violate email standards, especially when it comes to Unicode.

Does anyone know of something like this that already exists? It's not 
necessary for the package to actually send the emails, dumping them into 
an mbox is sufficient.


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

[RELEASED] Python 3.2.5 and Python 3.3.2

[Georg Brandl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On behalf of the Python development team, I am pleased to announce the
releases of Python 3.2.5 and 3.3.2.

The releases fix a few regressions in 3.2.4 and 3.3.1 in the zipfile, gzip
and xml.sax modules.  Details can be found in the changelogs:

http://hg.python.org/cpython/file/v3.2.5/Misc/NEWS  and
http://hg.python.org/cpython/file/v3.3.2/Misc/NEWS

To download Python 3.2.5 or Python 3.3.2, visit:

http://www.python.org/download/releases/3.2.5/  or
http://www.python.org/download/releases/3.3.2/

respectively.  As always, please report bugs to

http://bugs.python.org/

(Thank you to those who reported these regressions.)

Enjoy!

- -- 
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and all contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlGUbJ4ACgkQN9GcIYhpnLDH8ACdEM4k7bobLJsFmCb49zuwQR3W
EjgAoIWAOFNhJNdTAWEGSWqFWUP20wrb
=YnPr
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python for philosophers

[rusi]

On May 16, 6:17 am, Tim Daneliuk  wrote:
> On 05/15/2013 08:01 PM, Ned Batchelder wrote:
>
> > On 5/11/2013 4:03 PM, Citizen Kant wrote:
> >> Don't get me wrong. I can see the big picture and the amazing things that 
> >> programmers write on Python, it's just that my question points to the 
> >> lowest level of it's existence.
>
> > Sometimes a cigar is just a cigar.  Python is a tool, it does what you tell 
> > it.  To make an analogy, or maybe to clarify your philosophical view of the 
> > world, consider a hammer.  What is the "lowest level of its existence"?
>
> > --Ned.
>
> All You People are making this way too hard.  To understand how
> questions like the OPs ought be resolved, please read:
>
>    http://pvspade.com/Sartre/cookbook.html

Ha Ha! Very funny!
Also a serious reminder of what philosophy tends to become.
[Robert Pirsig wrote about the diff between philosophy and
philosophology]

>
> --
> 
> Tim Daneliuk     tun...@tundraware.com
> PGP Key:        http://www.tundraware.com/PGP/

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

Re: Python for philosophers

[Tim Daneliuk]

On 05/15/2013 11:49 PM, alex23 wrote:

On May 16, 11:17 am, Tim Daneliuk  wrote:

http://pvspade.com/Sartre/cookbook.html


Best recipe for tuna casserole ever! Cheers for this :)



"I have have realized that the traditional omelet form (eggs and cheese) is 
bourgeois."



--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

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

Re: Python for philosophers

[Tim Daneliuk]

On 05/15/2013 10:43 PM, Terry Jan Reedy wrote:

On 5/15/2013 9:17 PM, Tim Daneliuk wrote:


http://pvspade.com/Sartre/cookbook.html


Wikedly funny.




"Today I made a Black Forest cake out of five pounds of cherries and a live 
beaver,"

--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

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

Re: Python for philosophers

[alex23]

On May 16, 11:17 am, Tim Daneliuk  wrote:
>    http://pvspade.com/Sartre/cookbook.html

Best recipe for tuna casserole ever! Cheers for this :)

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

RE: [RELEASED] Python 2.7.5

[Carlos Nepomuceno]

test_asynchat still hangs! What it does? Should I care?


> Date: Wed, 15 May 2013 23:19:06 -0500
> Subject: [RELEASED] Python 2.7.5
> From: benja...@python.org
> To: python-...@python.org; python-list@python.org; 
> python-announce-l...@python.org
>
> It is my greatest pleasure to announce the release of Python 2.7.5.
>
> 2.7.5 is the latest maintenance release in the Python 2.7 series. You may be
> surprised to hear from me so soon, as Python 2.7.4 was released slightly more
> than a month ago. As it turns out, 2.7.4 had several regressions and
> incompatibilities with 2.7.3. Among them were regressions in the zipfile, 
> gzip,
> and logging modules. 2.7.5 fixes these. In addition, a data file for testing 
> in
> the 2.7.4 tarballs and binaries aroused the suspicion of some virus
> checkers. The 2.7.5 release removes this file to resolve that issue.
>
> For details, see the Misc/NEWS file in the distribution or view it at
>
> http://hg.python.org/cpython/file/ab05e7dd2788/Misc/NEWS
>
> Downloads are at
>
> http://python.org/download/releases/2.7.5/
>
> As always, please report bugs to
>
> http://bugs.python.org/
>
> (Thank you to those who reported these bugs in 2.7.4.)
>
> This is a production release.
>
> Happy May,
> Benjamin Peterson
> 2.7 Release Manager
> (on behalf of all of Python 2.7's contributors)
> --
> http://mail.python.org/mailman/listinfo/python-list   
>   
-- 
http://mail.python.org/mailman/listinfo/python-list

[RELEASED] Python 2.7.5

[Benjamin Peterson]

It is my greatest pleasure to announce the release of Python 2.7.5.

2.7.5 is the latest maintenance release in the Python 2.7 series. You may be
surprised to hear from me so soon, as Python 2.7.4 was released slightly more
than a month ago. As it turns out, 2.7.4 had several regressions and
incompatibilities with 2.7.3. Among them were regressions in the zipfile, gzip,
and logging modules. 2.7.5 fixes these. In addition, a data file for testing in
the 2.7.4 tarballs and binaries aroused the suspicion of some virus
checkers. The 2.7.5 release removes this file to resolve that issue.

For details, see the Misc/NEWS file in the distribution or view it at

http://hg.python.org/cpython/file/ab05e7dd2788/Misc/NEWS

Downloads are at

http://python.org/download/releases/2.7.5/

As always, please report bugs to

http://bugs.python.org/

(Thank you to those who reported these bugs in 2.7.4.)

This is a production release.

Happy May,
Benjamin Peterson
2.7 Release Manager
(on behalf of all of Python 2.7's contributors)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Software epigrams

[rusi]

On May 14, 8:08 am, Dan Sommers  wrote:
> On Tue, 14 May 2013 04:12:53 +1000, Chris Angelico wrote:
> > On Tue, May 14, 2013 at 4:02 AM, Skip Montanaro  wrote:
> >>> 8. A programming language is low level when its programs require
> >>> attention to the irrelevant.
> >> I think "irrelevant" in this context means stuff like memory
> >> management.
> > Sure. That one's pretty clear (if you care about memory management,
> > you want a low level language) ...
>
> http://www.memorymanagement.org/articles/lang.htmlsays:
>
>     C programmers think memory management is too important to be
>     left to the computer. Lisp programmers think memory management
>     is too important to be left to the user.
>
>     (from Ellis and Stroustrup's The Annotated C++ Reference Manual)

Notable physicist David Bohm wrote that the difficulty in
understanding quantum physics is largely a result of the limitation of
the subject-predicate format of Indo-European languages.

He suggested some experiments in languaging called rheomode that makes
English more process-oriented and less (abstract)noun oriented.

One part of this project is to learn to use the word 'relevate' --
which is 'relevant' verbified with an element of 'elevate' as in 'lift
into relief'

I guess the Ellis and Stroupstrup quote above just shows that C++
programmers relevate in one direction whereas Lisp programmers
relevate in another.

More http://www.mindstructures.com/2010/04/meaning-and-context/

Twenty two years ago I wrote about this 
http://www.the-magus.in/Publications/chor.pdf

Suddenly I am finding glowing references to this
http://dieswaytoofast.blogspot.in/2013/01/why-i-grown-to-loathe-c.html

And I am uneasy because these questions are far less rhetorical/
tautological than I imagines in 1990!

So here's a (rather incomplete/preliminary) rebuttal to myself
http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python for philosophers

[Terry Jan Reedy]

On 5/15/2013 9:17 PM, Tim Daneliuk wrote:


http://pvspade.com/Sartre/cookbook.html


Wikedly funny.


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

Re: python sockets question

[Andrew Berg]

On 2013.05.15 20:47, Eric Miller wrote:
> Can python sockets be used to capture IP traffic when the traffic is 
> originating from a non-python source?
Python just exposes the underlying OS socket interface. There is nothing 
special about sockets in Python. The whole point is to connect
heterogeneous systems. I can use Python on Windows to create a client that will 
connect to a service written in C running on Solaris or to
something written in Java running on Linux.

-- 
CPython 3.3.1 | Windows NT 6.2.9200 / FreeBSD 9.1
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.7.x - problem with obejct.__init__() not accepting *args and **kwargs

[Steven D'Aprano]

On Wed, 15 May 2013 13:16:09 +0100, Oscar Benjamin wrote:


> I don't generally use super() 

Then you should, especially in Python 3.

If you're not using super in single-inheritance classes, then you're 
merely making your own code harder to read and write, and unnecessarily 
difficult for others to use with multiple-inheritance.

If you're not using super in multiple-inheritance[1] classes, then your 
code is probably buggy.

There really is no good reason to avoid super in Python 3.


> but I did see some advice about it in this article:
> https://fuhm.net/super-harmful/

It's not a good article. The article started off claiming that super was 
harmful, hence the URL. He's had to back-pedal, and *hard*. The problem 
isn't that super is harmful, it is that the problem being solved -- 
generalized multiple inheritance -- is inherently a fiendishly difficult 
problem to solve. Using super and cooperative multiple inheritance makes 
it a merely difficult but tractable problem.

The above article is useful to see the sorts of issues that can come up 
in multiple inheritance, and perhaps as an argument for avoiding MI 
(except in the tamed versions provided by mixins or straits). But as an 
argument against super? No.

A much better article about super is:

http://rhettinger.wordpress.com/2011/05/26/super-considered-super/


> From the conclusion:
> "Never use positional arguments in __init__ or __new__. Always use
> keyword args, and always call them as keywords, and always pass all
> keywords on to super."

Even that advice is wrong. See Super Considered Super above.




[1] To be precise: one can write mixin classes without super, and 
strictly speaking mixins are a form of multiple inheritance, but it is a 
simplified version of multiple inheritance that avoids most of the 
complications.


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

python sockets question

[Eric Miller]

Can python sockets be used to capture IP traffic when the traffic is 
originating from a non-python source?

Using a Lantronix UDS-1100 serial to IP converter. The goal is to write a small 
proof of concept piece in Python to capture serial data output by this device 
over IP.

I've done a couple test projects using sockets in python, but they were all 
done between python processes (python > python): listen() on one end, and 
connect(), sendall() etc on the other.

I think I can use sockets for this project, but before I invest a bunch of time 
into it, wanted to make sure it is a viable solution.

Can python sockets be used to capture IP traffic when the traffic is 
originating from a non-python source? I have full control over the IP and port 
that the device sends the serial data to, but there will be no python connect() 
initiated by the client. I can pre-pend then serial data with some connect() 
string if needed.

If sockets won't work, please recommend another solution...guessing it will be 
REST or similar.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python for philosophers

[Tim Daneliuk]

On 05/15/2013 08:01 PM, Ned Batchelder wrote:

On 5/11/2013 4:03 PM, Citizen Kant wrote:

Don't get me wrong. I can see the big picture and the amazing things that 
programmers write on Python, it's just that my question points to the lowest 
level of it's existence.


Sometimes a cigar is just a cigar.  Python is a tool, it does what you tell it.  To make 
an analogy, or maybe to clarify your philosophical view of the world, consider a hammer.  
What is the "lowest level of its existence"?

--Ned.


All You People are making this way too hard.  To understand how
questions like the OPs ought be resolved, please read:

   http://pvspade.com/Sartre/cookbook.html




--

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

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

Re: Question re: objects and square grids

[Dave Angel]

On 05/15/2013 08:53 PM, Andrew Bradley wrote:



  

  So now, how can I utilize this new grid list? Thank you for the

help so far, I feel like the entire grid is now being worked out.
-Andrew



That's a Pygame question, and I told you at the beginning, I can't really
help with that.  I'd like to learn, but not this week.

Others - can you show some minimal code to use these grid parameters to
color selected squares of the pygame window?



Yes, I would very much like some help or general advice now about utilizing
this grid thing. How can I refer to these square's new numerical values to
do things with them? Will I be using things like "grid[0][1]" in specific
functions and methods to refer to squares now?


Yes, exactly.  Any place in your code (the part I cannot help with) that 
you need to specify a rect, you can specify something like grid[3][18]. 
 Eventually, as Ian pointed out, you'll want to store more information 
about each cell.  But at that time, you could have a more complex object 
(that YOU define) instead of just a rect.  I just don't think you're 
ready for defining such an object.



That is what I would like to
do, somehow.





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

Re: Python for philosophers

[Ned Batchelder]

On 5/11/2013 4:03 PM, Citizen Kant wrote:
Don't get me wrong. I can see the big picture and the amazing things 
that programmers write on Python, it's just that my question points to 
the lowest level of it's existence.


Sometimes a cigar is just a cigar.  Python is a tool, it does what you 
tell it.  To make an analogy, or maybe to clarify your philosophical 
view of the world, consider a hammer.  What is the "lowest level of its 
existence"?


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

Re: Question re: objects and square grids

[Andrew Bradley]

>
>
>  SQUARESIZE = 43
>>>
>>> grid = []
>>> for row in range(10):
>>>  row_squares = []
>>>  for column in range(20):
>>>  rect = Rect(12 + column * SQUARESIZE, 10 + row * SQUARESIZE,
>>> SQUARESIZE, SQUARESIZE)
>>>  row_squares.append(rect)
>>>  grid.append(row_squares)
>>>
>>> It appears to be working (that is, the program still runs without
>>> crashing).
>>>
>>
> Sorry, but that's no criteria.  Question is whether it's doing what you
> want.  Are the rows 20 across and are there 10 of them?  Do the values of
> each individual rect look right?  print is your friend.


Yes, I have gotten rid of that part with the 1, 2, 3, 4, etc., and now the
code appears to be working up to [9][19]. Thank you very much. The
coordinates all do look correct, and there are 200 rectangles when I do
list(grid).

>
>
>  So now, how can I utilize this new grid list? Thank you for the
>>> help so far, I feel like the entire grid is now being worked out.
>>> -Andrew
>>>
>>>
> That's a Pygame question, and I told you at the beginning, I can't really
> help with that.  I'd like to learn, but not this week.
>
> Others - can you show some minimal code to use these grid parameters to
> color selected squares of the pygame window?
>
>
Yes, I would very much like some help or general advice now about utilizing
this grid thing. How can I refer to these square's new numerical values to
do things with them? Will I be using things like "grid[0][1]" in specific
functions and methods to refer to squares now? That is what I would like to
do, somehow.

>
> --
> DaveA
> --
> http://mail.python.org/**mailman/listinfo/python-list
>

I apologize if these questions are too rudimentary--I am trying to wrap my
head around how this language works in a more general sense so I can start
applying it to things.
-Andrew
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Off topic] Software epigrams

[Fábio Santos]

On 15 May 2013 19:33, "Neil Cerutti"  wrote:
>
> On 2013-05-15, F?bio Santos  wrote:
> >> It is a tautology is disguise. When you use a low level
> >> language, low level details are relevant to the scope of your
> >> program.
> >
> > I don't see it that way. I think relevance and level are two
> > unrelated concepts.
> >
> > For example, in python you are handling irrelevant things if
> > you are trying to start a program and redirecting its standard
> > output into another program's standard input instead of just
> > using the shell and a pipe to do it.
> >
> > And in C you are just at the right level to write something for
> > a microchip, but then again you are doing a load of irrelevant
> > stuff if you need to work numbers larger than the maximum
> > permitted.
>
> If you need numbers larger than the maximum permitted then all
> the code you write to handle them is relevant.
>
> If I want to bake bread I hope I don't have to till a garden,
> plant the wheat, harvest the wheat, and grind the wheat. But
> gardening is relevant to bread baking weather or not I do it.
>
> --
> Neil Cerutti
> --
> http://mail.python.org/mailman/listinfo/python-list

Then memory management t is relevant to every python program even though
it's done by the interpreter?

And in Java we have factories, builders and builderfactories. What's so
relevant about them? Java is high level, no?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fwd: Fwd: Python for philosophers

[Fábio Santos]

On 15 May 2013 20:59, "Citizen Kant"  wrote:
> Of course one always may want to perform random hacking and turn tables
just because and treat the word python as a variable's name, setting that
python equals Monty Python in order to checkmate any given conversation. In
that case we'll have to cope then with the long lasting problem of being
forced to name every python snake as a Monty Python snake, due to the
caprice of a programmer .
>

In Python all variables are actually labels. Labels refer to an object. An
object can be referred to by any amount of labels, but when no labels and
other references remain "pointed at" it, garbage collection destroys the
object. So if we set python equals Monty Python the actual python snake
will actually cease to exist.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question re: objects and square grids

[Dave Angel]

Please put new comments AFTER the part you're quoting.  In other words, 
don't top-post.  Also please trim off the stuff that's no longer 
relevant, so people don't have to read through it all wondering where 
your implied comments are.


On 05/15/2013 06:48 PM, Andrew Bradley wrote:

ok, now I have tested this more thoroughly, and it seems i can only do the
grid[x][y] function up to grid[9][9], when i really should be able to be
doing up to grid[10][20].


No, you shouldn't expect it to go to 10,20.  Remember I said that Python 
is zero-based.  So it goes from 0 to 9 inclusive, and from 0 to 19 
inclusive.  Upper left corner is grid[0][0], while lower right is 
grid[9][19].  Check to make sure that range works, which I think it will.




What exactly is the function of this row_squares list?


It's a temporary to hold one row.  You could delete it after the outer 
loop ends, if you like. Normally, if this whole thing were inside a 
function, the variable would go away when the function ended, and you'd 
be returning the grid list only.


You could have avoided the separate name by doing some tricky syntax. 
But I'm trying to show you the clearest way of doing things from a 
beginner perspective.






On Wed, May 15, 2013 at 4:35 PM, Andrew Bradley wrote:


Now I want to show you what I have written:

row = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
column = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
18, 19, 20)


No point in initializing them to tuples, since you're not going to use 
those.  Besides, in a moment row and column become ints, and this just 
confuses things.  The range() function below builds a temporary list 
which looks just like what you tediously typed in (except it's square 
brackets instead of round).



SQUARESIZE = 43

grid = []
for row in range(10):
 row_squares = []
 for column in range(20):
 rect = Rect(12 + column * SQUARESIZE, 10 + row * SQUARESIZE,
SQUARESIZE, SQUARESIZE)
 row_squares.append(rect)
 grid.append(row_squares)

It appears to be working (that is, the program still runs without
crashing).


Sorry, but that's no criteria.  Question is whether it's doing what you 
want.  Are the rows 20 across and are there 10 of them?  Do the values 
of each individual rect look right?  print is your friend.



So now, how can I utilize this new grid list? Thank you for the
help so far, I feel like the entire grid is now being worked out.
-Andrew



That's a Pygame question, and I told you at the beginning, I can't 
really help with that.  I'd like to learn, but not this week.


Others - can you show some minimal code to use these grid parameters to 
color selected squares of the pygame window?


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

Re: Fractal

[alex23]

On May 15, 10:07 pm, "Colin J. Williams"  wrote:
> Google is your friend.  Try "Mandelbrot Python"

My favourite is this one:
http://preshing.com/20110926/high-resolution-mandelbrot-in-obfuscated-python
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Translation API in Python

[Chris Angelico]

On Thu, May 16, 2013 at 8:00 AM, Hala Gamal  wrote:
> I want to use A translator from Arabic to English and reverse in my 
> application which is written in pyhton,
> Is there  any open source Translator that can be used with python,
> Or Any Suggestion?
> Please Help,
> Thanks In Advance :)

I would recommend, in order:
1) Searching the Python modules [1]
2) Searching PyPI [2]
3) Searching the web [3]
4) Finding a translation program that uses stdin/stdout

I suspect #1 will come up blank, but any of the others could well come
up with something. Working with an external program is a bit harder
than an actual Python module, but it'll work.

ChrisA
[1] http://docs.python.org/3/
[2] https://pypi.python.org/pypi
[3] http://www.google.com/ or http://www.duckduckgo.com/ or
http://yahoo.com/ or whatever
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unicode humor

[alex23]

On May 16, 12:09 am, "D'Arcy J.M. Cain"  wrote:
> It's sort of like when Bush said "The French don't even have a word for
> entrepreneur."

Or "The Russians have no word for it, therefore detente must be a one-
way street."
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fwd: Fwd: Python for philosophers

[alex23]

On May 16, 5:55 am, Citizen Kant  wrote:
> As a matter of
> class, the word python names first a python snake than a Monty Python,
> which is 50% inspired by that python word, word that's been being
> considered the given name of a particular kind of snake since times in
> which Terry Gilliam wasn't even alive.

"Namespaces are one honking great idea -- let's do more of those!" Or
to put it another way: context is important.

I find it both funny and sad that you think the name of the language
is preventing _others_ from seeing it as it is, when you're the only
one who seems to be fixated upon it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question re: objects and square grids

[Andrew Bradley]

ok, now I have tested this more thoroughly, and it seems i can only do the
grid[x][y] function up to grid[9][9], when i really should be able to be
doing up to grid[10][20].
What exactly is the function of this row_squares list?



On Wed, May 15, 2013 at 4:35 PM, Andrew Bradley wrote:

> Now I want to show you what I have written:
>
> row = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
> column = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
> 18, 19, 20)
> SQUARESIZE = 43
>
> grid = []
> for row in range(10):
> row_squares = []
> for column in range(20):
> rect = Rect(12 + column * SQUARESIZE, 10 + row * SQUARESIZE,
> SQUARESIZE, SQUARESIZE)
> row_squares.append(rect)
> grid.append(row_squares)
>
> It appears to be working (that is, the program still runs without
> crashing). So now, how can I utilize this new grid list? Thank you for the
> help so far, I feel like the entire grid is now being worked out.
> -Andrew
>
>
>
> On Wed, May 15, 2013 at 3:57 PM, Dave Angel  wrote:
>
>> On 05/15/2013 02:14 PM, Andrew Bradley wrote:
>>
>> Please reply on the list, not privately, unless it's something like a
>> simple thank-you.  Typically, you'd do a reply-all, then delete the people
>> other than the list itself.  Or if you're using Thunderbird, you could just
>> reply-list.
>>
>> > Thank you very much for your response: it seems excellent, but I'm
>> afraid I
>> > do not understand it fully. Your code here:
>>
>> >
>> > maxrows = 10
>> > maxcols = 20
>> > grid = []
>> > for row in range(maxrows):
>> >  rowdata = []
>> >  for column in range(maxcols):
>> >  arg1 = ...
>> >  arg2 = ...
>> >  arg3 = ...
>> >  arg4 = ...
>> >  rowdata.append(pygame.Rect(arg
>> > 1, arg2, arg3, arg4)
>> >  grid.append(rowdata)
>> >
>> > Seems very good, but keep in mind I just started programming last week,
>> and
>> > this is hard for me to wrap my head around. Do I really just write grid
>> =
>> > []? or is this like a def grid(): function?
>>
>> This code was intended to replace the 200 lines you started, A1=
>> pygame... A2=  A3=   etc.  I'd have put them inside a function, but this is
>> just one of the things I'd have initialized in such a function.  grid is a
>> list of lists, not a function.
>>
>>
>> > What do you mean by rowdata = []?
>>
>> [] is the way you define an empty list.  Another way might be:
>> rowdata = list()
>>
>>
>> > And how exactly would I make the formula for a rect call?
>>
>> Well, for row==0 and col==0, you say you wanted 10, 12, 43, and 43 for
>> the four parameters.   But you never said how you were going to (manually)
>> calculate those numbers for other cells.  Only once you've decided that can
>> you fill in "formulas" for arg1 and arg2.  I suspect that arg3 and arg4 are
>> simply 43 and 43 respectively, since you want all the cells to be the same
>> size.
>>
>> taking my clue from Ian, I might try:
>>
>> x_offset = 10
>> y_offset = 12
>> width = height = 43
>> arg1 = column * width + x_offset
>> arg2 = row * height + y_offset
>> arg3 = width
>> arg4 = height
>>
>> That assumes that there is no gap between cells in this grid.  If you
>> want a gap, then the width value used in the arg1 formula would be more
>> than 43 (width).  Likewise the height value used in the arg2 formula would
>> be more than 43 (height).
>>
>> > If there's a good website for these kind of details, I would appreciate
>> that too.
>>
>> You cannot begin to write a non-trivial program in Python without
>> understanding lists pretty thoroughly.  Perhaps you should start with Alan
>> Gauld's tutorial, which doesn't assume previous programming experience.
>>http://www.alan-g.me.uk/
>>
>> I haven't studied it, as Python was about my 35th programming language.
>>  But he's very active on Python-tutor, and explains things very well. So
>> his website is probably very good as well.
>>
>> Now, as you can see from Ian's message, writing a game using pygame will
>> require quite a bit of other understanding.  He demonstrates with classes
>> to represent cells, which is indeed what I'd do.  But I suspect you're not
>> nearly ready to consider writing classes.  (You use classes all the time.
>>  For example, 5 is an instance of class int.)
>>
>>
>> --
>> DaveA
>>
>>
>>
>> --
>> DaveA
>> --
>> http://mail.python.org/**mailman/listinfo/python-list
>>
>
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Translation API in Python

[Hala Gamal]

I want to use A translator from Arabic to English and reverse in my application 
which is written in pyhton,
Is there  any open source Translator that can be used with python,
Or Any Suggestion?
Please Help,
Thanks In Advance :)
-- 
http://mail.python.org/mailman/listinfo/python-list

python 2.7 vs 2.5

[inq1ltd]

My web server is using python 2.5.

My cgi file is trying to open a shelve.

I xxx out some of the path below. 

I am trying to find out if this 
error is caused because I am using python 2.7 to write 
the cgi file and my web server is using python 2.5.

I would appreciate a confirmation of this.

 line 85, in FentriesFilled dbase = shelve.open( vpath, 'c' ) File 
"/usr/local/lib/python-2.5/lib/python2.5/shelve.py", line 225, in open return 
DbfilenameShelf(filename, flag, protocol, writeback) File 
"/usr/local/lib/python-2.5/lib/python2.5/shelve.py",

 line 209, in __init__ Shelf.__init__(self, anydbm.open(filename, flag), 
protocol, writeback) File "/usr/local/lib/python-2.5/lib/python2.5/anydbm.py", 
line 83, in open return mod.open(file, flag, mode) 

File "/usr/local/lib/python-2.5/lib/python2.5/dbhash.py", line 16, in open 
return bsddb.hashopen(file, flag, mode) 

File "/usr/local/lib/python-2.5/lib/python2.5/bsddb/__init__.py", line 306, in 
hashopen d.open(file, db.DB_HASH, flags, mode) bsddb.db.DBInvalidArgError: 
(22, 'Invalid argument --/home/users/web/x/yyy.inqvista/public_html/-
/email: unsupported hash version: 9') 

thanks,
jd



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

Immediate Position:::Business Analyst With BI EXP::::At Houston, TX

[susheel kumar]

Hi,

This is Girish, - Recruitment and Resources from SancroSoft USA Inc.

We have an urgent requirement as follows:

Please respond with resumes in MS-Word Format with the following
details togir...@sancrosoftusa.com

Full Name :
Location :
Contact Number :
Email :
Availability :
Visa Status :
Business Analyst & Data Analyst

Location: Houston, TX
Duration: 12 Months
Rate: Market

Job Description:

•  Total IT experience - 8-10 / 2-3 years as Business /
Data Analyst
•  Plan Requirement Gathering and Business Analysis
efforts
• Liaise with Business and IT teams to coordinate
interdependencies and resolve issues
• Interact with SMEs on functional needs to Gather & Analyze
the requirements
• Outline Operational Process and Identify any shortages in
terms of process or documentation
• Source System Data Analysis & Issue resolution
• Developing and maintaining technical documentation about the
data
• Conduct reviews and provide assistance to BA team members in
system documentation
• Co-ordination with technical team to resolve any data
related issues like date quality, data integrity
• Coordinates and conduct user acceptance testing.
• Facilitating end user training
•  Financial domain experience (Accounting, GL, AR, AP
etc) would be preferred
•  Experience in BI/DWH domain would be a plus
•  Excellent verbal and written communication
•  The candidate should be proactive, self motivated and
resourceful
•  Excellent interpersonal skills with an ability to build
effective relationships
•  Strong knowledge of all Microsoft Office tools
•  Excellent time management skills and working experience
on-shore/off-shore model

Thanks & Regards,
Girish
 IT Recruiter.


 The power of focus
SancroSoft USA INC
4944 Sunrise Blvd, Suite B-4 || Fair Oaks, CA 95628
Phone : 916-671-5591|| Fax: 916-200-0305
E-Mail : gir...@sancrosoftusa.com  www.sancrosoftusa.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Immediate Position:::Business Analyst With BI EXP::::At Houston, TX

[susheel kumar]

Hi,

This is Girish, - Recruitment and Resources from SancroSoft USA Inc.

We have an urgent requirement as follows:

Please respond with resumes in MS-Word Format with the following
details togir...@sancrosoftusa.com

Full Name :
Location :
Contact Number :
Email :
Availability :
Visa Status :
Business Analyst & Data Analyst

Location: Houston, TX
Duration: 12 Months
Rate: Market

Job Description:

•  Total IT experience - 8-10 / 2-3 years as Business /
Data Analyst
•  Plan Requirement Gathering and Business Analysis
efforts
• Liaise with Business and IT teams to coordinate
interdependencies and resolve issues
• Interact with SMEs on functional needs to Gather & Analyze
the requirements
• Outline Operational Process and Identify any shortages in
terms of process or documentation
• Source System Data Analysis & Issue resolution
• Developing and maintaining technical documentation about the
data
• Conduct reviews and provide assistance to BA team members in
system documentation
• Co-ordination with technical team to resolve any data
related issues like date quality, data integrity
• Coordinates and conduct user acceptance testing.
• Facilitating end user training
•  Financial domain experience (Accounting, GL, AR, AP
etc) would be preferred
•  Experience in BI/DWH domain would be a plus
•  Excellent verbal and written communication
•  The candidate should be proactive, self motivated and
resourceful
•  Excellent interpersonal skills with an ability to build
effective relationships
•  Strong knowledge of all Microsoft Office tools
•  Excellent time management skills and working experience
on-shore/off-shore model

Thanks & Regards,
Girish
 IT Recruiter.


 The power of focus
SancroSoft USA INC
4944 Sunrise Blvd, Suite B-4 || Fair Oaks, CA 95628
Phone : 916-671-5591|| Fax: 916-200-0305
E-Mail : gir...@sancrosoftusa.com  www.sancrosoftusa.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question re: objects and square grids

[Andrew Bradley]

Now I want to show you what I have written:

row = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
column = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18,
19, 20)
SQUARESIZE = 43

grid = []
for row in range(10):
row_squares = []
for column in range(20):
rect = Rect(12 + column * SQUARESIZE, 10 + row * SQUARESIZE,
SQUARESIZE, SQUARESIZE)
row_squares.append(rect)
grid.append(row_squares)

It appears to be working (that is, the program still runs without
crashing). So now, how can I utilize this new grid list? Thank you for the
help so far, I feel like the entire grid is now being worked out.
-Andrew



On Wed, May 15, 2013 at 3:57 PM, Dave Angel  wrote:

> On 05/15/2013 02:14 PM, Andrew Bradley wrote:
>
> Please reply on the list, not privately, unless it's something like a
> simple thank-you.  Typically, you'd do a reply-all, then delete the people
> other than the list itself.  Or if you're using Thunderbird, you could just
> reply-list.
>
> > Thank you very much for your response: it seems excellent, but I'm
> afraid I
> > do not understand it fully. Your code here:
>
> >
> > maxrows = 10
> > maxcols = 20
> > grid = []
> > for row in range(maxrows):
> >  rowdata = []
> >  for column in range(maxcols):
> >  arg1 = ...
> >  arg2 = ...
> >  arg3 = ...
> >  arg4 = ...
> >  rowdata.append(pygame.Rect(arg
> > 1, arg2, arg3, arg4)
> >  grid.append(rowdata)
> >
> > Seems very good, but keep in mind I just started programming last week,
> and
> > this is hard for me to wrap my head around. Do I really just write grid =
> > []? or is this like a def grid(): function?
>
> This code was intended to replace the 200 lines you started, A1= pygame...
> A2=  A3=   etc.  I'd have put them inside a function, but this is just one
> of the things I'd have initialized in such a function.  grid is a list of
> lists, not a function.
>
>
> > What do you mean by rowdata = []?
>
> [] is the way you define an empty list.  Another way might be:
> rowdata = list()
>
>
> > And how exactly would I make the formula for a rect call?
>
> Well, for row==0 and col==0, you say you wanted 10, 12, 43, and 43 for the
> four parameters.   But you never said how you were going to (manually)
> calculate those numbers for other cells.  Only once you've decided that can
> you fill in "formulas" for arg1 and arg2.  I suspect that arg3 and arg4 are
> simply 43 and 43 respectively, since you want all the cells to be the same
> size.
>
> taking my clue from Ian, I might try:
>
> x_offset = 10
> y_offset = 12
> width = height = 43
> arg1 = column * width + x_offset
> arg2 = row * height + y_offset
> arg3 = width
> arg4 = height
>
> That assumes that there is no gap between cells in this grid.  If you want
> a gap, then the width value used in the arg1 formula would be more than 43
> (width).  Likewise the height value used in the arg2 formula would be more
> than 43 (height).
>
> > If there's a good website for these kind of details, I would appreciate
> that too.
>
> You cannot begin to write a non-trivial program in Python without
> understanding lists pretty thoroughly.  Perhaps you should start with Alan
> Gauld's tutorial, which doesn't assume previous programming experience.
>http://www.alan-g.me.uk/
>
> I haven't studied it, as Python was about my 35th programming language.
>  But he's very active on Python-tutor, and explains things very well. So
> his website is probably very good as well.
>
> Now, as you can see from Ian's message, writing a game using pygame will
> require quite a bit of other understanding.  He demonstrates with classes
> to represent cells, which is indeed what I'd do.  But I suspect you're not
> nearly ready to consider writing classes.  (You use classes all the time.
>  For example, 5 is an instance of class int.)
>
>
> --
> DaveA
>
>
>
> --
> DaveA
> --
> http://mail.python.org/**mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question re: objects and square grids

[Dave Angel]

On 05/15/2013 02:14 PM, Andrew Bradley wrote:

Please reply on the list, not privately, unless it's something like a 
simple thank-you.  Typically, you'd do a reply-all, then delete the 
people other than the list itself.  Or if you're using Thunderbird, you 
could just reply-list.


> Thank you very much for your response: it seems excellent, but I'm 
afraid I

> do not understand it fully. Your code here:
>
> maxrows = 10
> maxcols = 20
> grid = []
> for row in range(maxrows):
>  rowdata = []
>  for column in range(maxcols):
>  arg1 = ...
>  arg2 = ...
>  arg3 = ...
>  arg4 = ...
>  rowdata.append(pygame.Rect(arg
> 1, arg2, arg3, arg4)
>  grid.append(rowdata)
>
> Seems very good, but keep in mind I just started programming last 
week, and

> this is hard for me to wrap my head around. Do I really just write grid =
> []? or is this like a def grid(): function?

This code was intended to replace the 200 lines you started, A1= 
pygame... A2=  A3=   etc.  I'd have put them inside a function, but this 
is just one of the things I'd have initialized in such a function.  grid 
is a list of lists, not a function.



> What do you mean by rowdata = []?

[] is the way you define an empty list.  Another way might be:
rowdata = list()


> And how exactly would I make the formula for a rect call?

Well, for row==0 and col==0, you say you wanted 10, 12, 43, and 43 for 
the four parameters.   But you never said how you were going to 
(manually) calculate those numbers for other cells.  Only once you've 
decided that can you fill in "formulas" for arg1 and arg2.  I suspect 
that arg3 and arg4 are simply 43 and 43 respectively, since you want all 
the cells to be the same size.


taking my clue from Ian, I might try:

x_offset = 10
y_offset = 12
width = height = 43
arg1 = column * width + x_offset
arg2 = row * height + y_offset
arg3 = width
arg4 = height

That assumes that there is no gap between cells in this grid.  If you 
want a gap, then the width value used in the arg1 formula would be more 
than 43 (width).  Likewise the height value used in the arg2 formula 
would be more than 43 (height).


> If there's a good website for these kind of details, I would 
appreciate that too.


You cannot begin to write a non-trivial program in Python without 
understanding lists pretty thoroughly.  Perhaps you should start with 
Alan Gauld's tutorial, which doesn't assume previous programming experience.

   http://www.alan-g.me.uk/

I haven't studied it, as Python was about my 35th programming language. 
 But he's very active on Python-tutor, and explains things very well. 
So his website is probably very good as well.


Now, as you can see from Ian's message, writing a game using pygame will 
require quite a bit of other understanding.  He demonstrates with 
classes to represent cells, which is indeed what I'd do.  But I suspect 
you're not nearly ready to consider writing classes.  (You use classes 
all the time.  For example, 5 is an instance of class int.)



--
DaveA


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

Fwd: Fwd: Python for philosophers

[Citizen Kant]

On 2013-05-14, Citizen Kant  wrote:
> 2013/5/14 Steven D'Aprano 
>
>> On Tue, 14 May 2013 01:32:43 +0200, Citizen Kant wrote:
>>
>> >> An entity named Python must be somehow as a serpent. Don't forget that
>> >> I'm with the freeing up of my memory, now I'm not trying to follow the
>> >> path of what's told but acting like the monkey and pushing with my
>> >> finger against the skin of the snake.
>>
>> >Python is not named after the snake, but after Monty Python the British
>> >comedy troupe. And they picked their name because it sounded funny.
>>
>> > http://en.wikipedia.org/wiki/Monty_Python<
http://en.wikipedia.org/wiki/Monty_Python>
>>
>> I'm sorry to hear that. Mostly because, as an answer, seems to example
>> very well the "taken because I've been told how things are" kind of
>> actions, which is exactly the opposite of the point I'm trying to state.

Grant Edwards said:

 Firstly, watch your quoting, Steve D'Aprano didn't write that despite
 your claim that he did.

 Secondly, if a the person who named something tells you they named it
 after A rather than B, what are you going to do other than "taken
 because I've been told".  Are you claiming Guido lied about the source
 of the name?

Of course not. I'm just claiming that the tree (what's been told) is
preventing him from seeing the forest (what it is). If what's been told was
(put, by the very God of Uranus) that "the name's origin resides on a
string, that string's made up with the entire text of The Bible's Genesis
chapter with the word Python inserted not exactly in the middle but upper
on that tree", now I would be claiming the very same thing. As a matter of
class, the word python names first a python snake than a Monty Python,
which is 50% inspired by that python word, word that's been being
considered the given name of a particular kind of snake since times in
which Terry Gilliam wasn't even alive. Of course one always may want to
perform random hacking and turn tables just because and treat the word
python as a variable's name, setting that python equals Monty Python in
order to checkmate any given conversation. In that case we'll have to cope
then with the long lasting problem of being forced to name every python
snake as a Monty Python snake, due to the caprice of a programmer .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unicode humor

[Colin J. Williams]

On 15/05/2013 1:21 PM, MRAB wrote:

On 15/05/2013 18:04, Jean-Michel Pichavant wrote:

- Original Message -

On 15/05/2013 14:19, Jean-Michel Pichavant wrote:

This reflects a lack of understanding of Unicode.



jmf



And this reflects a lack of a sense of humor.  :)


Isn't that a crime in the UK?

ChrisA


The problem with English humour (as against standard humor)
is that its not unicode compliant


British humour includes "double entendre", which is not
French-compliant.


I didn't get that one. Which possibly confirm MRAB's statement.


It's called "double entendre" in English (using French words, from
"à double entente"), but that isn't correct French ("double
sens").


Thanks for clarifying, I didn't know "double entendre" had actually a
meaning in english, it's obviously 2 french words but this is the
first time I see them used together.


Occasionally speakers of one language will borrow a word or phrase from
another language and use it in a way a native speaker wouldn't (or even
understand).


double-entendre - Chambers Fails, but see Wiktionary: 
http://en.wiktionary.org/wiki/double_entendre


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

Re: ssl proxy server

[Zachary Ware]

On Wed, May 15, 2013 at 1:58 PM, Chris “Kwpolska” Warrick
 wrote:
> On Tue, May 14, 2013 at 9:14 PM, Skip Montanaro  wrote:
>> I haven't touched the SpamBayes setup for the usenet-to-mail gateway
>> in a long while.  For whatever reason, this message was either held
>> and then approved by the current list moderator(s), or (more likely)
>> slipped through unscathed.  No filter is perfect.
>>
>> Skip
>
> A filter on this guy altogether would be.  He sent 24 messages there
> since February 25.  All of them spam.
>

You can always set your own filter.  I had been somewhat confused by
this thread until I realized the initial message had been killed by a
filter I set up a while back.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ssl proxy server

[Chris “Kwpolska” Warrick]

On Tue, May 14, 2013 at 9:14 PM, Skip Montanaro  wrote:
> I haven't touched the SpamBayes setup for the usenet-to-mail gateway
> in a long while.  For whatever reason, this message was either held
> and then approved by the current list moderator(s), or (more likely)
> slipped through unscathed.  No filter is perfect.
>
> Skip

A filter on this guy altogether would be.  He sent 24 messages there
since February 25.  All of them spam.

--
Kwpolska  | GPG KEY: 5EAAEA16
stop html mail| always bottom-post
http://asciiribbon.org| http://caliburn.nl/topposting.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Off topic] Software epigrams

[Neil Cerutti]

On 2013-05-15, F?bio Santos  wrote:
>> It is a tautology is disguise. When you use a low level
>> language, low level details are relevant to the scope of your
>> program.
>
> I don't see it that way. I think relevance and level are two
> unrelated concepts.
>
> For example, in python you are handling irrelevant things if
> you are trying to start a program and redirecting its standard
> output into another program's standard input instead of just
> using the shell and a pipe to do it.
>
> And in C you are just at the right level to write something for
> a microchip, but then again you are doing a load of irrelevant
> stuff if you need to work numbers larger than the maximum
> permitted.

If you need numbers larger than the maximum permitted then all
the code you write to handle them is relevant.

If I want to bake bread I hope I don't have to till a garden,
plant the wheat, harvest the wheat, and grind the wheat. But
gardening is relevant to bread baking weather or not I do it.

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

Re: Question re: objects and square grids

[Ian Kelly]

On Wed, May 15, 2013 at 10:56 AM, Andrew Bradley  wrote:
> Hello everyone.
>
> I am having a good time programming with Python 3.3 and Pygame. Pygame seems
> like the perfect platform for the kind of simple games that I want to make.
>
> What I have currently programmed is basically a drawn rectangle filled with
> 200 squares, each side of the squares being 43 pixels. The rectangle is 20
> squares by 10 squares.

It's more work, but I would recommend making the squares scalable in
some manner, instead of arbitrarily hard-coding them at 43 pixels.
What are you going to do when somebody has a 4K monitor and wants to
run the game full screen?

> This grid is what I want to have the entire game on. There will be pieces
> that move certain numbers of squares, perform actions that effect pieces on
> certain squares, etc. The possibilities are endless.
>
> So what I am now trying to do is organize these squares into objects that I
> can easily reference when programming things related to the squares.
>
> So far, I have done this:
>
> A1 = pygame.Rect(10, 12, 43, 43)
> A2
> A3
> A4
> B1
> B2
> etc.

This is a tedious, repetitive, and error-prone way to build all the
squares.  Instead of having a separate variable for each square,
consider putting them in a collection and building them up using
nested loops.  For example, the above could look something like:

squares = []
for row in range(10):
row_squares = []
for column in range(20):
rect = Rect(column * width + x_offset, row * height + y_offset,
width, height)
row_squares.append(rect)
squares.append(row_squares)

Then the A1 rect is accessible as squares[0][0], A2 as squares[0][1],
B1 as squares[1][0], etc.  Alternatively, you could store the rects in
a dict and use "A1", "B1", etc. as the keys, but I think you will find
that the game logic will be simpler if you use integers internally for
your rows and columns, rather than the square labels.

> where said integers are the precise location of the top left-most square for
> A1, and onward down the line. I would guess that I could continue on in such
> a fashion, with appropriate box names for each square. But I'm running into
> the problem of confirming that the code above actually does something
> useful. For example, I would love to be able to turn A1 a different color,
> but how does this work? How do I actually utilize these object variable
> names? Are there methods that I am not aware of, because most things I try
> tend to do nothing or crash the game. For example, A1.fill(BLUE) does not
> work.

A Rect only stores position and size information and provides methods
for processing the same.  It doesn't know anything about drawing.  Use
the pygame.draw or pygame.gfxdraw functions for that.  For example, to
fill a part of the screen as indicated by the position of a rect:

BLUE = (0, 0, 255)
pygame.draw.rect(screen, BLUE, squares[0][0])

That said, you probably don't just want to color a square blue.  You
probably also want to remember that the square is blue for when you
are redrawing it later.  You need to track not just the position of
each square, but also their state.  This means that each object in
your "squares" container should not just be a rect, but some broader
object that contains square data, *including* a rect.  Something like
this:

class Square:

def __init__(self, rect):
self.rect = rect
self.color = (0, 0, 0)
self.contents = None
# ... and whatever else you need to track

Then when you fill the squares container, you would fill it with
instances of your Square class instead of plain Rects, which gives you
a place to keep track of the square's color, among other things.  The
drawing code above then might look something like this:

pygame.draw.rect(screen, some_square.color, some_square.rect)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question re: objects and square grids

[Dave Angel]

On 05/15/2013 12:56 PM, Andrew Bradley wrote:

Hello everyone.

I am having a good time programming with Python 3.3 and Pygame. Pygame
seems like the perfect platform for the kind of simple games that I want to
make.



Pygame indeed looks pretty good to me as well.  But I haven't done 
anything with it, so I can't give you specific Pygame advice.




 

So far, I have done this:

A1 = pygame.Rect(10, 12, 43, 43)
A2
A3
A4
B1
B2
etc.



This is a code smell in Python (or any reasonable language).  I'd 
suggest that instead of trying to have 200 separate global variables, 
you have one, maybe called grid, as follows:


maxrows = 10
maxcols = 20
grid = []
for row in range(maxrows):
rowdata = []
for column in range(maxcols):
arg1 = ...
arg2 = ...
arg3 = ...
arg4 = ...
rowdata.append(pygame.Rect(arg1, arg2, arg3, arg4)
grid.append(rowdata)


Now, this can be done shorter with list comprehensions, but I figured 
this would be clearer for you.  I also may have the 10 and 20 reversed, 
but you can work that out.


You'd need to make four formulae to get the four arguments to the Rect 
call, using row and column respectively.  Remember that row and column 
will be numbered from zero, not from one.


But now, you can either address a single rect by
   grid[4][8]

or you can do something to all of them, or to an entire row, or to an 
entire column, pretty easily.



While you're testing your formulae, you might want to replace the 
rowdata.append line with something like:


rowdata.append( (arg1, arg2, arg3, arg4) )


And perhaps your maxrows, maxcols might be lower while you're testing.

And you can just print grid to see how those arguments are looking.

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

Re: [Off topic] Software epigrams

[Fábio Santos]

On 15 May 2013 18:29, "Neil Cerutti"  wrote:
>
> On 2013-05-13, F?bio Santos  wrote:
> >
> > On 13 May 2013 19:48, "Neil Cerutti"  wrote:
> >>
> >> On 2013-05-13, Skip Montanaro  wrote:
> >> >> 8. A programming language is low level when its programs
> >> >> require attention to the irrelevant.
> >> >>

(...)

> > It's not a tautology in disguise. Irrelevant != low level. When
> > low level details are relevant to the scope of my program, I
> > use a low level language.
>
> It is a tautology is disguise. When you use a low level language,
> low level details are relevant to the scope of your program.
>
> --
> Neil Cerutti
> --
> http://mail.python.org/mailman/listinfo/python-list

I don't see it that way. I think relevance and level are two unrelated
concepts.

For example, in python you are handling irrelevant things if you are trying
to start a program and redirecting its standard output into another
program's standard input instead of just using the shell and a pipe to do
it.

And in C you are just at the right level to write something for a
microchip, but then again you are doing a load of irrelevant stuff if you
need to work numbers larger than the maximum permitted.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unicode humor

[Jean-Michel Pichavant]

- Original Message -
> On Wed, 15 May 2013 15:19:00 +0200 (CEST)
> Jean-Michel Pichavant  wrote:
> > > British humour includes "double entendre", which is not
> > > French-compliant.
> > 
> > I didn't get that one. Which possibly confirm MRAB's statement.
> 
> It's sort of like when Bush said "The French don't even have a word
> for
> entrepreneur."
> 
> --
> D'Arcy J.M. Cain  |  Democracy is three
> wolves
> http://www.druid.net/darcy/|  and a sheep voting on
> +1 416 788 2246 (DoD#0082)(eNTP)   |  what's for dinner.
> IM: da...@vex.net, VOIP: sip:da...@vex.net

Nice one (to MRAB's credit his humor was intentional :o) )

JM 


-- IMPORTANT NOTICE: 

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

Re: [Off topic] Software epigrams

[Neil Cerutti]

On 2013-05-13, F?bio Santos  wrote:
>
> On 13 May 2013 19:48, "Neil Cerutti"  wrote:
>>
>> On 2013-05-13, Skip Montanaro  wrote:
>> >> 8. A programming language is low level when its programs
>> >> require attention to the irrelevant.
>> >>
>> >> So much a matter of debate. Indentation is irrelevant, why
>> >> should Python programs pay attention to it? Block delimiters
>> >> are irrelevant too, the interpreter should be able to figure
>> >> them out from the code layout. But this one is absolutely
>> >> right:
>> >
>> > I think "irrelevant" in this context means stuff like memory
>> > management.
>>
>> I thought I liked that one at first, but upon reflection it
>> speciously inserts the word "irrelevant" in order to avoid
>> stating a tautology: A programming language is low level when its
>> programs require attention to low level details.
>>
>> --
>> Neil Cerutti
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>
> It's not a tautology in disguise. Irrelevant != low level. When
> low level details are relevant to the scope of my program, I
> use a low level language.

It is a tautology is disguise. When you use a low level language,
low level details are relevant to the scope of your program.

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

Re: Unicode humor

[MRAB]

On 15/05/2013 18:04, Jean-Michel Pichavant wrote:

- Original Message -

On 15/05/2013 14:19, Jean-Michel Pichavant wrote:

This reflects a lack of understanding of Unicode.



jmf



And this reflects a lack of a sense of humor.  :)


Isn't that a crime in the UK?

ChrisA


The problem with English humour (as against standard humor)
is that its not unicode compliant


British humour includes "double entendre", which is not
French-compliant.


I didn't get that one. Which possibly confirm MRAB's statement.


It's called "double entendre" in English (using French words, from
"à double entente"), but that isn't correct French ("double
sens").


Thanks for clarifying, I didn't know "double entendre" had actually a
meaning in english, it's obviously 2 french words but this is the
first time I see them used together.


Occasionally speakers of one language will borrow a word or phrase from
another language and use it in a way a native speaker wouldn't (or even
understand).
--
http://mail.python.org/mailman/listinfo/python-list

Re: Unicode humor

[Jean-Michel Pichavant]

- Original Message -
> On 15/05/2013 14:19, Jean-Michel Pichavant wrote:
> >> >> >> This reflects a lack of understanding of Unicode.
> >> >>
> >> >> >> jmf
> >> >>
> >> >> > And this reflects a lack of a sense of humor.  :)
> >> >>
> >> >> Isn't that a crime in the UK?
> >> >>
> >> >> ChrisA
> >> >
> >> > The problem with English humour (as against standard humor) is
> >> > that
> >> > its not unicode compliant
> >> >
> >> British humour includes "double entendre", which is not
> >> French-compliant.
> >
> > I didn't get that one. Which possibly confirm MRAB's statement.
> >
> It's called "double entendre" in English (using French words, from "à
> double entente"), but that isn't correct French ("double sens").

Thanks for clarifying, I didn't know "double entendre" had actually a meaning 
in english, it's obviously 2 french words but this is the first time I see them 
used together.

JM


-- IMPORTANT NOTICE: 

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

Question re: objects and square grids

[Andrew Bradley]

Hello everyone.

I am having a good time programming with Python 3.3 and Pygame. Pygame
seems like the perfect platform for the kind of simple games that I want to
make.

What I have currently programmed is basically a drawn rectangle filled with
200 squares, each side of the squares being 43 pixels. The rectangle is 20
squares by 10 squares.

This grid is what I want to have the entire game on. There will be pieces
that move certain numbers of squares, perform actions that effect pieces on
certain squares, etc. The possibilities are endless.

So what I am now trying to do is organize these squares into objects that I
can easily reference when programming things related to the squares.

So far, I have done this:

A1 = pygame.Rect(10, 12, 43, 43)
A2
A3
A4
B1
B2
etc.

where said integers are the precise location of the top left-most square
for A1, and onward down the line. I would guess that I could continue on in
such a fashion, with appropriate box names for each square. But I'm running
into the problem of confirming that the code above actually does something
useful. For example, I would love to be able to turn A1 a different color,
but how does this work? How do I actually utilize these object variable
names? Are there methods that I am not aware of, because most things I try
tend to do nothing or crash the game. For example, A1.fill(BLUE) does not
work.

Any general advice about how to organize my squares into something that is
easy to program for would be VERY appreciated. Basically all the games I
want to make involve square grids like this, so I want to know as much
about them as possible.

Thank you very much for reading this,
Andrew
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Debugging difficulty in python with __getattr__, decorated properties and AttributeError.

[Mr. Joe]

On Wed, May 15, 2013 at 12:15 PM, dieter  wrote:
>
>   If Python would automatically redecorate overridden methods in a derived
>   class, I would have no control over the process. What if I need
>   the undecorated method or a differently decorated method (an
>   uncached or differently cached method, in my case)?
>

On a second thought, I am convinced by your argument.

> Your getter/setter use case can quite easily be solved
> with a class "DelayedMethodAccessor":
>
>   class DelayedMethodAccess(object):
> """
> def __init__(self, name): self.__name = name
> def __call__(self, inst, *args, **kw):
>   return getattr(inst, self.__name)(*args, **kw)
>
> You can then use:
>
>prop = property(DelayedMethodAccess(""), ...)
>
> Or define a new decorator "property_by_name" and then
> use
>
>prop = property_by_name("", ...)
>
> Of course, this requires that the property name and the getter/setter
names
> differ, but this should be naturally enough.
>
>
> Python's current behavior is very natural once you know that
> decorators are just syntactic sugar and
>
>@
>def ...
>
> simply means:
>
>def ...
>f = (f)
>
> True, this is no perfect fit for all use cases - but
> such a fit (if it existed at all) would have to be so complex
> that only experts could understand it.

Thanks for these really nice patterns. They fits my problem very well.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.7.x - problem with obejct.__init__() not accepting *args and **kwargs

[Ian Kelly]

On Wed, May 15, 2013 at 6:16 AM, Oscar Benjamin
 wrote:
> I don't generally use super() but I did see some advice about it in
> this article:
> https://fuhm.net/super-harmful/
>
> From the conclusion:
> "Never use positional arguments in __init__ or __new__. Always use
> keyword args, and always call them as keywords, and always pass all
> keywords on to super."

While that article is a good read, this one is a bit better on giving
advice about how to practically use super:

http://rhettinger.wordpress.com/2011/05/26/super-considered-super/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Determine actually given command line arguments

[Roy Smith]

In article ,
Henry Leyh   wrote:
>On 15.05.2013 14:24, Roy Smith wrote:
>> In article ,
>>   Henry Leyh  wrote:
>>
>>> Is there a simple way to determine which
>>> command line arguments were actually given on the commandline, i.e. does
>>> argparse.ArgumentParser() know which of its namespace members were
>>> actually hit during parse_args().
>>
>> I think what you're looking for is sys.argv:
>>
>> $ cat argv.py
>> import sys
>> print sys.argv
>>
>> $ python argv.py foo bar
>> ['argv.py', 'foo', 'bar']
>
>Thanks, but as I wrote in my first posting I am aware of sys.argv and 
>was hoping to _avoid_ using it because I'd then have to kind of 
>re-implement a lot of the stuff already there in argparse, e.g. parsing 
>sys.argv for short/long options, flag/parameter options etc.

Sorry, I missed that.

I'm not clear on exactly what you're trying to do.  You say:

> Now I would also like the program to be able to _write_ a 
> configparser config file that contains only the parameters actually 
> given on the commandline. 

I'm guessing what you're trying to do is parse the command line first,
then anything that was set there can get overridden by a value in the
config file?  That seems backwards.  Usually, the order is:

1) built-in default
2) config file (possibly a system config file, then a per-user one)
3) environment variable
4) command-line argument

It sounds like you're doing it in the reverse order -- allowing the
config file to override the command line.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fractal

[Ian Kelly]

On Mon, May 13, 2013 at 9:41 AM, Sharon COUKA  wrote:
> Hello, I'm new to python and i have to make a Mandelbrot fractal image for 
> school but I don't know how to zoom in my image.
> Thank you for helping me.

Is this a GUI application or does it just write the image to a file?
What GUI / image library are you using?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Determine actually given command line arguments

[Skip Montanaro]

> However, maybe I could ...

... switch to getopt? 

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

Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ]

[Alister]

 
> != is explicit.
> 
> There is no ambiguity that needs to be guessed.

Which is why i said it thought X != Y is cleaner
i guess i wasn't totally clear, I would write  X != Y its because the OP 
preferred to use the other format I recommended that he made the operator 
ordering explicit.


-- 
Nature abhors a virgin -- a frozen asset.
-- Clare Booth Luce
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Determine actually given command line arguments

[Henry Leyh]

On 15.05.2013 16:08, Skip Montanaro wrote:

Yes, I was trying that and it sort of works with strings if I use something sufficiently improbable 
like "__UNSELECTED__" as default.  But it gets difficult with boolean or even number 
arguments where you just may not have valid "improbable" defaults.  You could now say, so 
what, it's the default anyway.  But in my program I would like to distinguish between given and not 
given arguments rather than between default and non-default.


Initialize all your arg variables to None, then after command line
processing, any which remain as None weren't set on the command line.
At that point, set them to the actual defaults.  I think that's a
pretty common idiom.

Note: I am an old cranky dude and still use getopt.  This idiom is
pretty easy there.  YMMV with argparse or optparse.


Unfortunately, argparse wants to know the type of the argument and the 
boolean arguments (those with action=store_true) can't be initialized 
with None.


However, maybe I could convert boolean arguments to something like

  parser.add_argument('--foo', type=str, nargs='?', const='True', 
default=None)


I'd then have to check for string 'True' rather than for boolean True, 
though.


Regards,
Henry

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

Re: Fwd: Python for philosophers

[Grant Edwards]

On 2013-05-14, Citizen Kant  wrote:
> 2013/5/14 Steven D'Aprano 
>
>> On Tue, 14 May 2013 01:32:43 +0200, Citizen Kant wrote:
>>
>> >> An entity named Python must be somehow as a serpent. Don't forget that
>> >> I'm with the freeing up of my memory, now I'm not trying to follow the
>> >> path of what's told but acting like the monkey and pushing with my
>> >> finger against the skin of the snake.
>>
>> >Python is not named after the snake, but after Monty Python the British
>> >comedy troupe. And they picked their name because it sounded funny.
>>
>> > http://en.wikipedia.org/wiki/Monty_Python
>>
>> I'm sorry to hear that. Mostly because, as an answer, seems to example
>> very well the "taken because I've been told how things are" kind of
>> actions, which is exactly the opposite of the point I'm trying to state.

Firstly, watch your quoting, Steve D'Aprano didn't write that despite
your claim that he did.

Secondly, if a the person who named something tells you they named it
after A rather than B, what are you going to do other than "taken
because I've been told".  Are you claiming Guido lied about the source
of the name?

-- 
Grant Edwards   grant.b.edwardsYow! My life is a patio
  at   of fun!
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Fractal

[Grant Edwards]

On 2013-05-13, Sharon COUKA  wrote:

> Hello, I'm new to python and i have to make a Mandelbrot fractal image for 
> school but I don't know how to zoom in my image.
> Thank you for helping me.

It's a fractal image, so you zoom in/out with the following Python
instruction:

   pass

;)

-- 
Grant Edwards   grant.b.edwardsYow! I'm not available
  at   for comment..
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unicode humor

[MRAB]

On 15/05/2013 14:19, Jean-Michel Pichavant wrote:

>> >> This reflects a lack of understanding of Unicode.
>>
>> >> jmf
>>
>> > And this reflects a lack of a sense of humor.  :)
>>
>> Isn't that a crime in the UK?
>>
>> ChrisA
>
> The problem with English humour (as against standard humor) is that
> its not unicode compliant
>
British humour includes "double entendre", which is not
French-compliant.


I didn't get that one. Which possibly confirm MRAB's statement.


It's called "double entendre" in English (using French words, from "à
double entente"), but that isn't correct French ("double sens").

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

Re: Determine actually given command line arguments

[Wayne Werner]

On Wed, 15 May 2013, Henry Leyh wrote:
Yes, I was trying that and it sort of works with strings if I use something 
sufficiently improbable like "__UNSELECTED__" as default.  But it gets 
difficult with boolean or even number arguments where you just may not have 
valid "improbable" defaults.  You could now say, so what, it's the default 
anyway.  But in my program I would like to distinguish between given and not 
given arguments rather than between default and non-default.


Have you looked into docopt? It's pretty awesome, and might really help in 
this case.


HTH,
-W
--
http://mail.python.org/mailman/listinfo/python-list

Re: Unicode humor

[D'Arcy J.M. Cain]

On Wed, 15 May 2013 15:19:00 +0200 (CEST)
Jean-Michel Pichavant  wrote:
> > British humour includes "double entendre", which is not
> > French-compliant.
> 
> I didn't get that one. Which possibly confirm MRAB's statement.

It's sort of like when Bush said "The French don't even have a word for
entrepreneur."

-- 
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 788 2246 (DoD#0082)(eNTP)   |  what's for dinner.
IM: da...@vex.net, VOIP: sip:da...@vex.net
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Determine actually given command line arguments

[Skip Montanaro]

> Yes, I was trying that and it sort of works with strings if I use something 
> sufficiently improbable like "__UNSELECTED__" as default.  But it gets 
> difficult with boolean or even number arguments where you just may not have 
> valid "improbable" defaults.  You could now say, so what, it's the default 
> anyway.  But in my program I would like to distinguish between given and not 
> given arguments rather than between default and non-default.

Initialize all your arg variables to None, then after command line
processing, any which remain as None weren't set on the command line.
At that point, set them to the actual defaults.  I think that's a
pretty common idiom.

Note: I am an old cranky dude and still use getopt.  This idiom is
pretty easy there.  YMMV with argparse or optparse.

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

Re: Determine actually given command line arguments

[Henry Leyh]

On 15.05.2013 15:00, Oscar Benjamin wrote:

On 15 May 2013 13:52, Henry Leyh  wrote:

On 15.05.2013 14:24, Roy Smith wrote:


In article ,
   Henry Leyh  wrote:


Is there a simple way to determine which
command line arguments were actually given on the commandline, i.e. does
argparse.ArgumentParser() know which of its namespace members were
actually hit during parse_args().



I think what you're looking for is sys.argv:

$ cat argv.py
import sys
print sys.argv

$ python argv.py foo bar
['argv.py', 'foo', 'bar']


Thanks, but as I wrote in my first posting I am aware of sys.argv and was
hoping to _avoid_ using it because I'd then have to kind of re-implement a
lot of the stuff already there in argparse, e.g. parsing sys.argv for
short/long options, flag/parameter options etc.

I was thinking of maybe some sort of flag that argparse sets on those
optional arguments created with add_argument() that are really given on the
command line, i.e. those that it stumbles upon them during parse_args().


I don't know about that but I imagine that you could compare values
with their defaults to see which have been changed.


Yes, I was trying that and it sort of works with strings if I use 
something sufficiently improbable like "__UNSELECTED__" as default.  But 
it gets difficult with boolean or even number arguments where you just 
may not have valid "improbable" defaults.  You could now say, so what, 
it's the default anyway.  But in my program I would like to distinguish 
between given and not given arguments rather than between default and 
non-default.


Regards,
Henry

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

Re: Unicode humor

[Jean-Michel Pichavant]

> >> >> This reflects a lack of understanding of Unicode.
> >>
> >> >> jmf
> >>
> >> > And this reflects a lack of a sense of humor.  :)
> >>
> >> Isn't that a crime in the UK?
> >>
> >> ChrisA
> >
> > The problem with English humour (as against standard humor) is that
> > its not unicode compliant
> >
> British humour includes "double entendre", which is not
> French-compliant.

I didn't get that one. Which possibly confirm MRAB's statement.

JM


-- IMPORTANT NOTICE: 

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

Re: Determine actually given command line arguments

[Oscar Benjamin]

On 15 May 2013 13:52, Henry Leyh  wrote:
> On 15.05.2013 14:24, Roy Smith wrote:
>>
>> In article ,
>>   Henry Leyh  wrote:
>>
>>> Is there a simple way to determine which
>>> command line arguments were actually given on the commandline, i.e. does
>>> argparse.ArgumentParser() know which of its namespace members were
>>> actually hit during parse_args().
>>
>>
>> I think what you're looking for is sys.argv:
>>
>> $ cat argv.py
>> import sys
>> print sys.argv
>>
>> $ python argv.py foo bar
>> ['argv.py', 'foo', 'bar']
>
> Thanks, but as I wrote in my first posting I am aware of sys.argv and was
> hoping to _avoid_ using it because I'd then have to kind of re-implement a
> lot of the stuff already there in argparse, e.g. parsing sys.argv for
> short/long options, flag/parameter options etc.
>
> I was thinking of maybe some sort of flag that argparse sets on those
> optional arguments created with add_argument() that are really given on the
> command line, i.e. those that it stumbles upon them during parse_args().

I don't know about that but I imagine that you could compare values
with their defaults to see which have been changed.


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

Re: Determine actually given command line arguments

[Henry Leyh]

On 15.05.2013 14:24, Roy Smith wrote:

In article ,
  Henry Leyh  wrote:


Is there a simple way to determine which
command line arguments were actually given on the commandline, i.e. does
argparse.ArgumentParser() know which of its namespace members were
actually hit during parse_args().


I think what you're looking for is sys.argv:

$ cat argv.py
import sys
print sys.argv

$ python argv.py foo bar
['argv.py', 'foo', 'bar']


Thanks, but as I wrote in my first posting I am aware of sys.argv and 
was hoping to _avoid_ using it because I'd then have to kind of 
re-implement a lot of the stuff already there in argparse, e.g. parsing 
sys.argv for short/long options, flag/parameter options etc.


I was thinking of maybe some sort of flag that argparse sets on those 
optional arguments created with add_argument() that are really given on 
the command line, i.e. those that it stumbles upon them during parse_args().


Regards,
Henry

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

Re: Determine actually given command line arguments

[Jussi Piitulainen]

Colin J. Williams writes:

> On 15/05/2013 2:34 AM, Henry Leyh wrote:
> > Hello,

> > I am writing a program that gets its parameters from a combination
> > of config file (using configparser) and command line arguments
> > (using argparse).  Now I would also like the program to be able to
> > _write_ a configparser config file that contains only the
> > parameters actually given on the commandline.  Is there a simple
> > way to determine which command line arguments were actually given
> > on the commandline, i.e. does argparse.ArgumentParser() know which
> > of its namespace members were actually hit during parse_args().
> >
> > I have tried giving the arguments default values and then looking
> > for those having a non-default value but this is really awkward,
> > especially if it comes to non-string arguments.  Also, parsing
> > sys.argv looks clumsy because you have to keep track of short and
> > long options with and without argument etc. i.e. all things that I
> > got argparse for in the first place.
> >
> > Thanks && Greetings,
> > Henry

> Try sys.argv

You people should read what you quote, or what you don't quote when
you cut the relevant portion.

Q. ... parsing sys.argv looks clumsy because  ...
A. Try sys.argv

I mean, huh?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Determine actually given command line arguments

[Dave Angel]

On 05/15/2013 08:24 AM, Roy Smith wrote:

In article ,
  Henry Leyh  wrote:


Is there a simple way to determine which
command line arguments were actually given on the commandline, i.e. does
argparse.ArgumentParser() know which of its namespace members were
actually hit during parse_args().


I think what you're looking for is sys.argv:

$ cat argv.py
import sys
print sys.argv

$ python argv.py foo bar
['argv.py', 'foo', 'bar']



Colin & Roy:
The OP mentioned sys.argv in his original query.

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

Re: Determine actually given command line arguments

[Roy Smith]

In article ,
 Henry Leyh  wrote:

> Is there a simple way to determine which 
> command line arguments were actually given on the commandline, i.e. does 
> argparse.ArgumentParser() know which of its namespace members were 
> actually hit during parse_args().

I think what you're looking for is sys.argv:

$ cat argv.py
import sys
print sys.argv

$ python argv.py foo bar
['argv.py', 'foo', 'bar']
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python 2.7.x - problem with obejct.__init__() not accepting *args and **kwargs

[Oscar Benjamin]

On 15 May 2013 12:18, wzab  wrote:
> I had to implement in Python 2.7.x a system which heavily relies on
> multiple inheritance.
> Working on that, I have came to very simplistic code which isolates
> the problem:
> (The essential thing is that each base class receives all arguments
> and uses only those,
> which it understands).
>
[snip]
>
> I have found a workaround:
>
> # Class my_object added only as workaround for a problem with
> # object.__init__() not accepting any arguments.
[snip]
>
> The above works correctly, producing the same results as the first
> code in Python 2.5.2,
> but anyway it seems to me just a dirty trick...
> What is the proper way to solve that problem in Python 2.7.3?

I don't generally use super() but I did see some advice about it in
this article:
https://fuhm.net/super-harmful/

>From the conclusion:
"Never use positional arguments in __init__ or __new__. Always use
keyword args, and always call them as keywords, and always pass all
keywords on to super."


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

Re: Fractal

[Colin J. Williams]

On 13/05/2013 11:41 AM, Sharon COUKA wrote:

Hello, I'm new to python and i have to make a Mandelbrot fractal image for 
school but I don't know how to zoom in my image.
Thank you for helping me.

Envoyé de mon iPad



Google is your friend.  Try "Mandelbrot Python"

Colin W.




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

Re: Determine actually given command line arguments

[Colin J. Williams]

On 15/05/2013 2:34 AM, Henry Leyh wrote:

Hello,
I am writing a program that gets its parameters from a combination of
config file (using configparser) and command line arguments (using
argparse).  Now I would also like the program to be able to _write_ a
configparser config file that contains only the parameters actually
given on the commandline.  Is there a simple way to determine which
command line arguments were actually given on the commandline, i.e. does
argparse.ArgumentParser() know which of its namespace members were
actually hit during parse_args().

I have tried giving the arguments default values and then looking for
those having a non-default value but this is really awkward, especially
if it comes to non-string arguments.  Also, parsing sys.argv looks
clumsy because you have to keep track of short and long options with and
without argument etc. i.e. all things that I got argparse for in the
first place.

Thanks && Greetings,
Henry

Try sys.argv

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

Python 2.7.x - problem with obejct.__init__() not accepting *args and **kwargs

[wzab]

I had to implement in Python 2.7.x a system which heavily relies on
multiple inheritance.
Working on that, I have came to very simplistic code which isolates
the problem:
(The essential thing is that each base class receives all arguments
and uses only those,
which it understands).

class a(object):
  def __init__(self,*args,**kwargs):
super(a,self).__init__(*args,**kwargs)
print args
print kwargs
print "init in a"

class b(object):
  def __init__(self,*args,**kwargs):
super(b,self).__init__(*args,**kwargs)
print args
print kwargs
print "init in b"

class c(a,b):
  def __init__(self,*args,**kwargs):
super(c,self).__init__(*args,**kwargs)
print args
print kwargs
print "init in c"

z=c(test=23,data="eee")

In Python 2.5.2 the above code works correctly, and produces:

$python test1.py
()
{'test': 23, 'data': 'eee'}
init in b
()
{'test': 23, 'data': 'eee'}
init in a
()
{'test': 23, 'data': 'eee'}
init in c

Unfortunately in Python 2.7 the above code generates an exception:
$ python test1.py
Traceback (most recent call last):
  File "test1.py", line 22, in 
z=c(test=23,data="eee")
  File "test1.py", line 17, in __init__
super(c,self).__init__(*args,**kwargs)
  File "test1.py", line 3, in __init__
super(a,self).__init__(*args,**kwargs)
  File "test1.py", line 10, in __init__
super(b,self).__init__(*args,**kwargs)
TypeError: object.__init__() takes no parameters

I have found a workaround:

# Class my_object added only as workaround for a problem with
# object.__init__() not accepting any arguments.

class my_object(object):
  def __init__(self,*args,**kwargs):
super(my_object,self).__init__()

class a(my_object):
  def __init__(self,*args,**kwargs):
super(a,self).__init__(*args,**kwargs)
print args
print kwargs
print "init in a"

class b(my_object):
  def __init__(self,*args,**kwargs):
super(b,self).__init__(*args,**kwargs)
print args
print kwargs
print "init in b"

class c(a,b):
  def __init__(self,*args,**kwargs):
super(c,self).__init__(*args,**kwargs)
print args
print kwargs
print "init in c"

z=c(test=23,data="eee")

The above works correctly, producing the same results as the first
code in Python 2.5.2,
but anyway it seems to me just a dirty trick...
What is the proper way to solve that problem in Python 2.7.3?

--
TIA,
Wojtek
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Message passing syntax for objects | OOPv2

[Ian Kelly]

On Sun, May 12, 2013 at 10:48 PM, Mark Janssen
 wrote:
> You're very right.  But that is what has made it sort of a test-bed
> for internet collaboration.   The project I'm working on is aimed to
> solve that problem and take the Wiki philosophy to its next or even
> ultimate level.  By adding a "natural" per-revision voting and
> user-ranking it can clear up all the noise and scale to the whole
> internet itself.  But no one around here seem to think its
> possible.

I may have missed it in the noise, but I don't recall that you ever
proposed such a project "around here".  That said, your brief
description does sound rather like Cloud Cuckoo Land to me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python for philosophers

[Chris Angelico]

On Tue, May 14, 2013 at 4:14 AM, rusi  wrote:
> It costs $10K for a car which goes at around 80 kmph
>
> Now if I want to move at 800 kmph I need to switch from car to plane
> and that will cost me in millions
>
> And if I want to move at 8000 kmph I need to be in a rocket in outer
> space. Cost perhaps in billions
>
> And maybe if I spend in trillions (leaving aside the question where I
> got the trillions) maybe my rocket can go at 80,000 kmph
>
> So what will it cost me to have a rocket that will go at 300,000 m/sec
> (186,000 miles per second may be more familiar)?

A $1 pocket flashlight.

:)

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

Fractal

[Sharon COUKA]

Hello, I'm new to python and i have to make a Mandelbrot fractal image for 
school but I don't know how to zoom in my image.
Thank you for helping me.

Envoyé de mon iPad
-- 
http://mail.python.org/mailman/listinfo/python-list