Re: repr/str diff between Python 2 and 3

[Serhiy Storchaka]

On 12.10.16 04:30, Skip Montanaro wrote:

  https://docs.python.org/3/whatsnew/3.1.html

It's the third hit when searching for 'float'.  Assuming I understand

what it's saying. ;)

Thanks. Is that the "David Gay's algorithm"? That seems to apply only to
repr(), while the change I observed was in str().


In Python 2 str() for floats was equivalent to '%.12g' % x, and repr() 
-- to '%.17g' % x. In Python 3.0 str() becomes the same as repr() (this 
added too much noise). In Python 3.1 repr() (and therefore str()) was 
changed to produce more compact representation if possible. This change 
was backported to 2.7, but str() left different.



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

Re: Python-based monads essay (Re: Assignment versus binding)

[Gregory Ewing]

Paul Rubin wrote:

Also if this operation is what it looks like, it's usually called
"bind".  seq is something else entirely.


Ah, I hadn't realised there was already a function in
Haskell called seq -- sorry about that!

I don't really want to call the Python version 'bind',
because it seems a bit obscure. Also, the way I'm using
it there, it's not actually binding anything (it
corresponds to >> rather than >>=), so calling it
'bind' would just confuse matters.

I'll see if I can come up with a better name for it
that doesn't clash with anything.

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

Re: Python-based monads essay (Re: Assignment versus binding)

[Gregory Ewing]

Anuradha Laxminarayan wrote:

seq f g h = f (\s1 -> g h s1)

better be written as

seq f g x = f (\s1 -> g x s1)

because naming conventions imply that h is function.


Well, for the subset of monads I'm talking about, it
always is a function -- it's the continuation to be
run after f and g.

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

Re: Pip error on installing Python 3.5

[Zachary Ware]

On Tue, Oct 11, 2016 at 7:07 PM, Steve D'Aprano
 wrote:
> I've just installed Python 3.5 from the source tarball and received an
> unexpected error related to pip. On Linux, as a regular user (except for
> the last line):
>
>
> wget https://www.python.org/ftp/python/3.5.2/Python-3.5.2.tgz
> tar xvf Python-3.5.2.tgz
> cd Python-3.5.2
> ./configure
> make
> sudo make altinstall
>
>
> There were no obvious errors until the end:
>
> The directory '/home/steve/.cache/pip/http' or its parent directory is not
> owned by the current user and the cache has been disabled. Please check the
> permissions and owner of that directory. If executing pip with sudo, you
> may want sudo's -H flag.
>
> Ignoring indexes: https://pypi.python.org/simple
>
> The directory '/home/steve/.cache/pip' or its parent directory is not owned
> by the current user and caching wheels has been disabled. check the
> permissions and owner of that directory. If executing pip with sudo, you
> may want sudo's -H flag.
>
>
>
> Can anyone explain what is going on, why I should care, and how I should fix
> it?

Those aren't errors, and pip should be perfectly usable.  The message
about `/home/steve/.cache/pip` is just because pip is being run via
sudo; pip's cache dir is based on $HOME, which is still set to
`/home/steve` and pip doesn't want to screw up its cache for the
`steve` user.  The "Ignoring indexes" message is due to ensurepip
explicitly disabling pulling from PyPI when installing pip and
setuptools.

The messages about the cache do look a bit unnecessarily scary, it
might be nice if they didn't appear when pip is run by ensurepip.  I'm
not sure what removing the message for that particular case might
entail, but it might be worth opening an issue for it.

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

Re: Is it possible Python can distinguish capital letter and small letter in the path of Windows?

[Gregory Ewing]

Dennis Lee Bieber wrote:

VMS documentation set was around 60 linear inches (two 30" shelves) of
3-ring binders. Amiga RKMs were five volumes with the main documentation in
fine print -- two "pages" side-by-side on a landscape page.


Apparently if you're writing software for the US Air Force,
minimum documentation requirements are measured in metres.
Although it seems it doesn't matter much whether all of
those metres are actually useful...

http://thedailywtf.com/articles/Very,_Very_Well_Documented

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

Re: OFF TOPIC mov is Turing complete

[Michael Torrie]

On 10/11/2016 09:19 PM, Steven D'Aprano wrote:
> Completely off-topic, but too awesome not to share:
> 
> The x86 assembly language "mov" instruction is Turing complete:
> 
> https://www.cl.cam.ac.uk/~sd601/papers/mov.pdf

And apparently someone has taken this and made a small C compiler that
compiles to nothing but mov instructions. Amazing:
https://github.com/xoreaxeaxeax/movfuscator

Now I'm sure malware writers will take full advantage of this to make
reverse-engineering of their code difficult!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is it possible Python can distinguish capital letter and small letter in the path of Windows?

[eryk sun]

On Wed, Oct 12, 2016 at 2:36 AM,   wrote:
>
> I had try to find the document of the _winapi module, but can't find any in my
> installed Python directory. Can you give me a link to look for?

_winapi is not documented. It contains light wrappers around a small
set of Windows functions. It's ok for quick scripts if it has what you
need. But for everything else you should prefer the publicly
documented PyWin32 package, ctypes, or CFFI.

>> This alone doesn't make the Windows API case sensitive, but it does
>> enable individual CreateFile calls to be case sensitive, via the POSIX
>> semantics flag.
>
> Does it means that an application program which uses the POSIX semantics flag 
> in its
> API call will perform case-sensitive automatically after the 
> "obcaseinsensitive" flag was
> modified by the user?

FILE_FLAG_POSIX_SEMANTICS has to be specified in every CreateFile call.

The real system call is NtCreateFile. Like all other named objects in
the NT kernel, a file path is passed to NtCreateFile in a
OBJECT_ATTRIBUTES structure, which can be flagged as
OBJ_CASE_INSENSITIVE. When WinAPI CreateFile calls NtCreateFile, it
almost always uses the OBJ_CASE_INSENSITIVE flag. The exception is
when the caller requests FILE_FLAG_POSIX_SEMANTICS.

However, the latter is no longer enough in Windows XP and later (NT
5.1+), for which the default was switched to case insensitive for all
object manager and I/O manager objects such as devices and files. To
get the old behavior back, and thus fix the now broken
FILE_FLAG_POSIX_SEMANTICS flag, you have to disable the
ObCaseInsensitive setting, as I showed.

This modification is best for administrative and short-term use, or
for systems running an NFS server. As a long-term setting it may be
problematic. Notably SQL Server and the Windows 10 Subsystem for Linux
(WSL) don't work properly if ObCaseInsensitive is disabled.
-- 
https://mail.python.org/mailman/listinfo/python-list

OFF TOPIC mov is Turing complete

[Steven D'Aprano]

Completely off-topic, but too awesome not to share:

The x86 assembly language "mov" instruction is Turing complete:

https://www.cl.cam.ac.uk/~sd601/papers/mov.pdf

Abstract

It is well-known that the x86 instruction set is baroque, overcom-
plicated, and redundantly redundant. We show just how much fluff
it has by demonstrating that it remains Turing-complete when re-
duced to just one instruction.

The  instruction  we  choose  is mov,  which can do both loads and stores. We 
use no unusual addressing modes, self-modifying code, or runtime code 
generation. Using just this instruction (and a single unconditional branch at 
the end of the program to make nontermination possible), we demonstrate how an 
arbitrary Turing machine can be simulated.





-- 
Steven
git gets easier once you get the basic idea that branches are homeomorphic 
endofunctors mapping submanifolds of a Hilbert space.

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

Re: repr/str diff between Python 2 and 3

[Terry Reedy]

On 10/11/2016 9:30 PM, Skip Montanaro wrote:

  https://docs.python.org/3/whatsnew/3.1.html

It's the third hit when searching for 'float'.  Assuming I understand

what it's saying. ;)

Thanks. Is that the "David Gay's algorithm"? That seems to apply only to
repr(), while the change I observed was in str().


Since str(float) is now, I believe, the same as repr(float), it means 
that in general, you have two possible changes to str ;-).


--
Terry Jan Reedy

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

Re: repr/str diff between Python 2 and 3

[Ethan Furman]

On 10/11/2016 06:30 PM, Skip Montanaro wrote:

https://docs.python.org/3/whatsnew/3.1.html

It's the third hit when searching for 'float'.  Assuming I understand what it's 
saying. ;)


Thanks. Is that the "David Gay's algorithm"? That seems to apply only to 
repr(), while the change I observed was in str().


But if __str__ is not defined, __repr__ is used.  And I believe that is the 
case with float.  Too lazy to check, though.  ;)

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

Re: Is it possible Python can distinguish capital letter and small letter in the path of Windows?

[jfong]

wxjm...@gmail.com at 2016/10/11 9:40:21PM wrote:
> If you are about to modify your registry, do not
> forget to switch your Windows in a *utf-8 mode*.

Have no idea how to "switch" Windows in a "utf-8 mode"? What will happens if 
not? Can you give a simple example? Thanks ahead.

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

Re: Is it possible Python can distinguish capital letter and small letter in the path of Windows?

[jfong]

Hi, eryk, thanks for your solution.

I had try to find the document of the _winapi module, but can't find any in my 
installed Python directory. Can you give me a link to look for?

> This alone doesn't make the Windows API case sensitive, but it does
> enable individual CreateFile calls to be case sensitive, via the POSIX
> semantics flag.

Does it means that an application program which uses the POSIX semantics flag 
in its API call will perform case-sensitive automatically after the 
"obcaseinsensitive" flag was modified by the user?

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

Re: repr/str diff between Python 2 and 3

[Ben Finney]

Skip Montanaro  writes:

> > Only that one should not rely on ‘str’ preserving the value accurately,
> > as documented in Python 2.
>
> Sure, but this choice is out of my hands. It's csv.writerow that calls
> str(), not me.

Ah, good old ‘csv’.

If the implementation is leaking an abstraction and you can't change the
implementation, then yes, making your test cases aware of the difference
is an option you'll need to consider.

-- 
 \  “Do I believe in God? … without clarification of a kind I have |
  `\never seen, I don’t know whether I believe or don’t believe in |
_o__)whatever a questioner has in mind.” —Noam Chomsky |
Ben Finney

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

Re: repr/str diff between Python 2 and 3

[Terry Reedy]

On 10/11/2016 8:59 PM, Skip Montanaro wrote:

I'm trying to port some code from Python 2 to 3, and beyond the usual
mechanical stuff, I've encountered a difference between the str() of
floats. Here's an example. In Python 3 I get:


print(repr(27.04 - 0.01))

27.028

print(str(27.04 - 0.01))

27.028

but in Python 2 str() behaves differently:


print repr(27.04 - 0.01)

27.028

print str(27.04 - 0.01)

27.03

My test case writes through a csv writer, which writes the str() of each
element to the output. My test assertions are looking at the output, not
the numeric input, so the option to test if the number is "close enough"
isn't readily available. I suppose I should adjust my test case, as in this
case 27.04-0.01 is different than 27.03.


Or you can make the text version-specific.

Basing tests on strings generated by Python is fragile because they are 
subject to change.  For instance, 3.1 has a new algorithm for 
repr(float), discussed in What's New in 3.1.  The repr for other objects 
can and does change with new versions, as to exception messages.  (They 
are only changed in bugfix releases if there is a real and significant 
but.)



Is there documentation of this particular change? My searching turned up
documentation of plenty of other changes, but not this particular one.


There was discussed on the development lists.  I believe this change was 
in 3.0, in which case there would be no mention in the 3.x docs.  I did 
not see mention in What New in 3.0, though.  The change would certainly 
be in the NEWS file that lists all commits.  This is now reformatted 
into an html changelog linked from What's New, but this started after in 
3.0.


--
Terry Jan Reedy

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

Re: repr/str diff between Python 2 and 3

[Skip Montanaro]

> Only that one should not rely on ‘str’ preserving the value accurately,
> as documented in Python 2.

Sure, but this choice is out of my hands. It's csv.writerow that calls
str(), not me. I could probably subclass csv.writer and csv.DictWriter, and
override the writerow method, but I would prefer not to if I can avoid it.
I could also propose a change to the writerow method, but - even if
accepted - it wouldn't change earlier 3.x behavior.

Skip

> --
>  \  “[Entrenched media corporations will] maintain the status quo, |
>   `\   or die trying. Either is better than actually WORKING for a |
> _o__)  living.” —ringsnake.livejournal.com, 2007-11-12 |
> Ben Finney
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: repr/str diff between Python 2 and 3

[Skip Montanaro]

>   https://docs.python.org/3/whatsnew/3.1.html
>
> It's the third hit when searching for 'float'.  Assuming I understand
what it's saying. ;)

Thanks. Is that the "David Gay's algorithm"? That seems to apply only to
repr(), while the change I observed was in str().

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

Re: repr/str diff between Python 2 and 3

[Ben Finney]

Skip Montanaro  writes:

> >>> print repr(27.04 - 0.01)
> 27.028
> >>> print str(27.04 - 0.01)
> 27.03
>
> My test case writes through a csv writer, which writes the str() of each
> element to the output.

For Python 2, that's a mistake:

str(object='')

Return a string containing a nicely printable representation of an
object. […] The difference with repr(object) is that str(object)
does not always attempt to return a string that is acceptable to
eval(); its goal is to return a printable string. […]

https://docs.python.org/2/library/functions.html#str>

So, for preserving the value, you don't want ‘str(obj)’. That's what
‘repr(obj)’ is for:

repr(object)

Return a string containing a printable representation of an object.
[…] For many types, this function makes an attempt to return a
string that would yield an object with the same value when passed to
eval() […]

https://docs.python.org/2/library/functions.html#repr>

> Is there documentation of this particular change? My searching turned
> up documentation of plenty of other changes, but not this particular
> one.

Only that one should not rely on ‘str’ preserving the value accurately,
as documented in Python 2.

-- 
 \  “[Entrenched media corporations will] maintain the status quo, |
  `\   or die trying. Either is better than actually WORKING for a |
_o__)  living.” —ringsnake.livejournal.com, 2007-11-12 |
Ben Finney

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

Re: repr/str diff between Python 2 and 3

[Ethan Furman]

On 10/11/2016 05:59 PM, Skip Montanaro wrote:


Is there documentation of this particular change? My searching turned up
documentation of plenty of other changes, but not this particular one.


3.1 What's new:

  https://docs.python.org/3/whatsnew/3.1.html

It's the third hit when searching for 'float'.  Assuming I understand what it's 
saying. ;)

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

repr/str diff between Python 2 and 3

[Skip Montanaro]

I'm trying to port some code from Python 2 to 3, and beyond the usual
mechanical stuff, I've encountered a difference between the str() of
floats. Here's an example. In Python 3 I get:

>>> print(repr(27.04 - 0.01))
27.028
>>> print(str(27.04 - 0.01))
27.028

but in Python 2 str() behaves differently:

>>> print repr(27.04 - 0.01)
27.028
>>> print str(27.04 - 0.01)
27.03

My test case writes through a csv writer, which writes the str() of each
element to the output. My test assertions are looking at the output, not
the numeric input, so the option to test if the number is "close enough"
isn't readily available. I suppose I should adjust my test case, as in this
case 27.04-0.01 is different than 27.03.

Is there documentation of this particular change? My searching turned up
documentation of plenty of other changes, but not this particular one.

Thx,

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

Pip error on installing Python 3.5

[Steve D'Aprano]

I've just installed Python 3.5 from the source tarball and received an
unexpected error related to pip. On Linux, as a regular user (except for
the last line):


wget https://www.python.org/ftp/python/3.5.2/Python-3.5.2.tgz
tar xvf Python-3.5.2.tgz
cd Python-3.5.2
./configure
make
sudo make altinstall


There were no obvious errors until the end:

The directory '/home/steve/.cache/pip/http' or its parent directory is not
owned by the current user and the cache has been disabled. Please check the
permissions and owner of that directory. If executing pip with sudo, you
may want sudo's -H flag.

Ignoring indexes: https://pypi.python.org/simple

The directory '/home/steve/.cache/pip' or its parent directory is not owned
by the current user and caching wheels has been disabled. check the
permissions and owner of that directory. If executing pip with sudo, you
may want sudo's -H flag.



Can anyone explain what is going on, why I should care, and how I should fix
it?





-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: How to process syntax errors

[Terry Reedy]

On 10/11/2016 4:02 AM, Pierre-Alain Dorange wrote:


Using this function, the code is "compiled".
I do not think this function is often used and most python project
simply use the interpreter (which do a small translation into byte-code
to be faster and check syntax error before running interpretation


You seem to be confusing CPython with, for instance, simple BASIC 
interpreters that tokenized the code, translated keywords to function 
numbers, and did other 'small translations' before execution.


The CPython compiler lexes (tokenizes), ll(1) parses to a syntax tree, 
does some analysis and transformation of the tree, and translates it to 
the bytecode for an stack machine.  All done using standard compiler theory.


One can even ask compile() to stop with the syntax tree and return that 
instead of a code object.  One can then do one's own tree manipulation 
and even code generation.



So yes there is a way to check "syntax error" before executing code
(using compile function and exceptions) but it was not standard,

>  nor widely used...

In CPython, the built-in Python-visible compile function *is* the 
CPython compile function used to compile *all* python code.  Leaving out 
interaction with the OS and initialization, one could loosely define 
CPython as exec(compile(open('x.py').read())).


--
Terry Jan Reedy

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

Re: shadows name from outer scope

[Terry Reedy]

On 10/11/2016 11:50 AM, Daiyue Weng wrote:

Hi, I have the following code structure,

def one_func(param1, param2, param3):

process_outcome = {'dict': None}


outcome = another_func(param1, process_outcome, db_host=param2,
funcs_to_run=param3)

PyCharm warns me

Shadows name from outer scope

on every variable here, param1,2,3, process_outcome.


Have you checked that this is true?  Code checkers sometimes have bugs. 
In any case, we cannot comment on this without code.



I am wondering how to resolve the issues,


Ignore the warning or turn it off.


and is it vital to have variables not shadowed?


No, sometimes it is the right thing to do.  Some warnings dependably 
indicate something wrong.  Some do not and are just a hint that maybe 
you should think about what you did.  Was it accidental (a typo) or 
intentional?


--
Terry Jan Reedy

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

Re: while loop (Reposting On Python-List Prohibited)

[BartC]

On 11/10/2016 22:26, Lawrence D’Oliveiro wrote:

On Wednesday, October 12, 2016 at 6:58:46 AM UTC+13, dhawan...@gmail.com wrote:

Only first loop is executing not the second one?


n=6
x=1
while x<=n:
print("*"*x)
x+=1
print('n=', n)
print('x=', x)
while n>=x:
n=n-1
print("*"* n)

*
**
***

*
**
n= 6
x= 7

Moral: always use debug print statements to figure out what is going on.



'else' can be used here:

n=6
x=1
while x<=n:
print "*"*x
x+=1

while n>=x:
n=n-1
print "*"* n
else:
print ("2nd loop exit n=",n,"x=",x)

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

Re: Python Shell in Russian exists/possible??

[Андрей Логунов]

среда, 12 октября 2016 г., 4:29:02 UTC+10 пользователь Michael Torrie написал:
> On 10/11/2016 05:33 AM, Андрей Логунов wrote:
> > I need the Python Shell for use in education (turtle graphics, etc.),
> > but the UI must be localized in the Russian language. The question is
> > if it's at all possible to feed the strings in or rebuild it or...
> 
> For educational purposes, you might find the Jupyter Notebook to be
> worthwhile.  It's the interactive Python interpreter but in a format you
> can use from the browser and it acts like a notebook too, allowing
> editing and actually building of code from interactive snippets.  There
> is some effort underway to build localization of language into it.
> Unfortunately this effort is in its early stages.
> 
> There's also a module someone wrote for it to let you do the turtle
> graphics module inside the notebook.
> 
> Anyway, if they had localization all finished, I'd say Jupyter Notebook
> would be the way to go for your purposes.

Thanks for the leads,
B.R.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Conventions and requirements for a python module

[Michael Felt]

On 11/10/2016 17:30, Michael Torrie wrote:

On 10/11/2016 08:29 AM, Michael Felt wrote:

  From reading the python source, and other projects I am looking to
patch I see that there is often a file __init__.py, sometimes empty
(only comments), sometimes not.

I have tried looking in what I hope are the "regular" places such as:
https://docs.python.org, readthedocs (it took 454 seconds to build
something - what did it build, and where do I get it? I was assuming it
was "latest documentation" and I even tried the old, no-longer
maintained, wiki.

A search for __init__.py, except for on https://packaging.python.org/
that talks about a setup command to extract the version from __init__.py
- I have not been able to find anything on "standards" for packages that
are more than a single .py file.

Probably, I am not looking correctly - however, I do hope someone also
notices that finding this is not straight forward for a novice in
python. Had I lacked curiosity I would have given up, moved on. Instead
- this email.

Yes all this is in the docs:
https://docs.python.org/3/tutorial/modules.html#packages

Thanks!


Also there are links that show up when searching google for "python
packages":
http://www.learnpython.org/en/Modules_and_Packages
http://docs.python-guide.org/en/latest/writing/structure/#packages

And again!

Packages are convenient for organizing code. Typically I put code into
__init__.py to organize the package's symbols. In other words whatever
symbols get imported when the package is imported are defined here.
Sometimes I'll import things from sub-modules from within __init__.py
and name and organize them.  Sometimes submodules are left on their own
to be imported separately.  Though the notation "from foo import *" is
discouraged, if a programmer is wont to do that, the package can limit
the damage somewhat by defining the __all__ variable.


As I said, probably not looking correctly - looking under the wrong 
baskets. Tutorials is not where I usually look first - I like them 
better after I have done some basic reading to confirm and/or correct my 
expectations.



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

Re: Python code is compiled before execution

[BartC]

On 11/10/2016 18:14, Steve D'Aprano wrote:

On Wed, 12 Oct 2016 12:19 am, BartC wrote:


Python is not really suited for AOT native-code compilation.


You might be right, but the author of Nuitka disagrees.

http://nuitka.net/


I tried the same thing with a dynamic language: translating byte-code 
into a series of function calls in a compiled language. So it wasn't 
really compiling to proper native code; the native code still had to 
deal with the byte-code rather than do the work directly.


It didn't really work: I saved the minor overheads of byte-code 
dispatching, but it ended up being slower than byte-code. (Perhaps to do 
with worse cache performance and fewer inlining opportunities.)


From looking at the overview in that link, it might be taking a similar 
approach. But maybe CPython dispatch overheads are higher, or maybe it 
just does a better job!


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

Re: Not getting output

[BartC]

On 11/10/2016 18:57, dhawanpawa...@gmail.com wrote:

def abc(a,b):
l=[]
for i in range(a,b+1):
if i%2!=0:

l.append(i)
print l
return 1

def bg():
y=abc(11,31)
print y
I am not getting the output, but if i call method abc outside the function then 
it's coming



Try adding:

bg()

at the end in order to call bg.

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

Re: while loop

[Jussi Piitulainen]

dhawanpawa...@gmail.com writes:

> n=6
> x=1
> while x<=n:
> print "*"*x
> x+=1
> while n>=x:
> n=n-1
> print "*"* n
>
>   
> Only first loop is executing not the second one?

It's a basic fact about while loops that after the loop the condition is
false. The two conditions x <= n and n >= x are equivalent.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Not getting output

[Michael Torrie]

On 10/11/2016 11:57 AM, dhawanpawa...@gmail.com wrote:
> def abc(a,b):
> l=[]
> for i in range(a,b+1):
> if i%2!=0:
> 
> l.append(i)
> print l
> return 1
> 
> def bg():
> y=abc(11,31)
> print y
> I am not getting the output, but if i call method abc outside the function 
> then it's coming

Is this your entire program?  Because all I see are two function
definitions.  You have no code that actually calls either of these two
functions from the main level of your code.  Remember that Python
executes scripts in a procedural manner.

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

Re: Not getting output

[Jussi Piitulainen]

dhawanpawa...@gmail.com writes:

> def abc(a,b):
> l=[]
> for i in range(a,b+1):
> if i%2!=0:
> 
> l.append(i)
> print l
> return 1
>
> def bg():
> y=abc(11,31)
> print y
>
> I am not getting the output, but if i call method abc outside the
> function then it's coming

Do you perhaps expect abc to return the list that it builds and prints?
If so, use some other name than l. One that doesn't look so much like
the number 1.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: while loop

[Michael Torrie]

On 10/11/2016 11:58 AM, dhawanpawa...@gmail.com wrote:
> 
> n=6
> x=1
> while x<=n:
> print "*"*x
> x+=1
> while n>=x:
> n=n-1
> print "*"* n
> 
>   
> Only first loop is executing not the second one?

Did you try printing out the loop variable to see what it does and what
it is after the loop is finished?

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

Re: Python Shell in Russian exists/possible??

[Michael Torrie]

On 10/11/2016 05:33 AM, Андрей Логунов wrote:
> I need the Python Shell for use in education (turtle graphics, etc.),
> but the UI must be localized in the Russian language. The question is
> if it's at all possible to feed the strings in or rebuild it or...

For educational purposes, you might find the Jupyter Notebook to be
worthwhile.  It's the interactive Python interpreter but in a format you
can use from the browser and it acts like a notebook too, allowing
editing and actually building of code from interactive snippets.  There
is some effort underway to build localization of language into it.
Unfortunately this effort is in its early stages.

There's also a module someone wrote for it to let you do the turtle
graphics module inside the notebook.

Anyway, if they had localization all finished, I'd say Jupyter Notebook
would be the way to go for your purposes.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: while loop

[Larry Martell]

On Tue, Oct 11, 2016 at 1:58 PM,   wrote:
>
> n=6
> x=1
> while x<=n:
> print "*"*x
> x+=1
> while n>=x:
> n=n-1
> print "*"* n
>
>
> Only first loop is executing not the second one?

Because after the first loop n < x
-- 
https://mail.python.org/mailman/listinfo/python-list

while loop

[dhawanpawan32]

n=6
x=1
while x<=n:
print "*"*x
x+=1
while n>=x:
n=n-1
print "*"* n

  
Only first loop is executing not the second one?
-- 
https://mail.python.org/mailman/listinfo/python-list

Not getting output

[dhawanpawan32]

def abc(a,b):
l=[]
for i in range(a,b+1):
if i%2!=0:

l.append(i)
print l
return 1

def bg():
y=abc(11,31)
print y
I am not getting the output, but if i call method abc outside the function then 
it's coming
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python-based monads essay (Re: Assignment versus binding)

[Rustom Mody]

On Tuesday, October 11, 2016 at 9:53:25 PM UTC+5:30, Anuradha Laxminarayan 
wrote:
> On Sunday, 9 October 2016 13:18:32 UTC+5:30, Gregory Ewing  wrote:
> > Here's the first part of the essay I said I'd write about
> > monads:
> > 
> > http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html
> > 
> > Hope it's useful,
> > Greg
> 
> Thanks, that made a very interesting read.

Yeah agreed!

Just got it running in ghc.
Some small modifications needed:

import Data.Set

add x f s = f (insert x s)
listify f s = f (toList s) s
seqq f g x = f (\s1 -> g x s1)

dedup (x:t) = seqq (add x) (dedup t)
dedup [] = listify

run_smf f a = f a (\r s -> r) empty

> seq f g h = f (\s1 -> g h s1)

> better be written as

> seq f g x = f (\s1 -> g x s1)

> because naming conventions imply that h is function.

I think it would be good to make state and adhere to a name-convention eg
c for continuation
f,g for general function
s for state
etc

Otherwise excellent work! V useful
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python-based monads essay (Re: Assignment versus binding)

[Paul Rubin]

Anuradha Laxminarayan  writes:
> seq f g x = f (\s1 -> g x s1)
> because naming conventions imply that h is function.

Also if this operation is what it looks like, it's usually called
"bind".  seq is something else entirely.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python code is compiled before execution

[Steve D'Aprano]

On Wed, 12 Oct 2016 12:19 am, BartC wrote:

> Python is not really suited for AOT native-code compilation.

You might be right, but the author of Nuitka disagrees.

http://nuitka.net/


Nice to see that there's a new release, only a week or so ago!




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: How to process syntax errors

[Steve D'Aprano]

On Tue, 11 Oct 2016 03:58 pm, Terry Reedy wrote:

> On 10/10/2016 11:24 AM, Chris Angelico wrote:
>> On Tue, Oct 11, 2016 at 1:13 AM,   wrote:
>>> Is there any way to capture syntax errors and process them ? I want to
>>> write a function which calls every time whenever there is syntax error
>>> in the program.
> 
>> However, you can catch this at some form of outer level. If you're
>> using exec/eval to run the code, you can guard that:
>>
>> code = """
>> obj = MyClass() # using PEP 8 names
>> obj xyz
>> """
>> try:
>> exec(code)
>> except SyntaxError:
>> print("Blah blah blah")
> 
> Far from being 'un-pythonic' (Puneet's response), this is essentially
> what the interpreter does, either without or with a separate explicit
> compile step.

There is a *huge* difference between writing an interpreter which takes
source code written in idiomatic Python:

# source code looks like this
x = [1, 2]
y = len(x)
print(y + 1)


reading that source code into a string (either all at once, or a line at a
time), then using exec() to execute the string:

try:
exec(source_code)
except SyntaxError:
# emit error


and what I believe the OP wishes to do, which is to put the entire source
code inside a call to exec:

# source code looks like this:
try:
text = """\
x = [1, 2]
y = len(x)
print(y + 1)
"""
exec(text)
except SyntaxError:
# recover from syntax error somehow, and keep processing


What the OP appears to want is not to write Python code at all, but to write
something where function calls are delimited with spaces:

# source code looks like this:
try:
text = """\
x = [1, 2]
y = len x
print y + 1
"""
exec(text)
except SyntaxError:
# automatically re-format the syntax errors into legal 
# Python code and execute again


See the OP's thread with subject 

"A newbie doubt on methods/functions calling"

from last week. I believe that he hasn't given up on the hope to avoid
writing parentheses and just use spaces, even though we've already
explained that is ambiguous:

func a b c
# is that func(a, b, c) or func(a(b, c)) or func(a, b(c)) or ... ?

I don't believe that mr.puneet.goyal is planning to write an interpreter for
Python. I believe that he's hoping to find some trick or hack so he can
avoid parentheses for function calls, and he hopes that by catching
SyntaxError he can do this.


But I could be wrong... 



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Python Shell in Russian exists/possible??

[Steve D'Aprano]

On Tue, 11 Oct 2016 10:33 pm, Андрей Логунов wrote:

> I need the Python Shell for use in education (turtle graphics, etc.), but
> the UI must be localized in the Russian language. The question is if it's
> at all possible to feed the strings in or rebuild it or...

Yes it is possible, but it is probably a lot of work.

There are at least two projects for localising Python into non-English. One
is a "toy" project, just to show that it can be done:

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

but I understand that the second is quite serious:

http://www.chinesepython.org/english/english.html

or at least was very serious a few years ago. Unfortunately I don't know if
it is still maintained.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Python code is compiled before execution

[Pierre-Alain Dorange]

Grant Edwards  wrote:

> > For my part, i differenciate a strict compilation (ie. C) from a
> > translation into byte-code (ie. Python).
> 
> FWIW I've seen C compilers that produced byte-code.  They allowed for
> a highly interactive developemnt environment.

I do not want to fight every word and every context.
As said before, in real world, all is possible and all situation is
possible : from pure interpreter to pure compiler (low level machine
language

I just want, at the beginning to point that, by principe Python was an
interpreted language, and i found strange the initial request. 
And sure, i overinterpret or simplify thing (compiling)...

But it seems that all this talk do not interested the initial requester
(Mr Puneet) : at that time he has not answer to the thread.

-- 
Pierre-Alain Dorange   Moof 

Ce message est sous licence Creative Commons "by-nc-sa-2.0"

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

Re: Python code is compiled before execution

[Grant Edwards]

On 2016-10-11, Pierre-Alain Dorange  wrote:

> For my part, i differenciate a strict compilation (ie. C) from a
> translation into byte-code (ie. Python).

FWIW I've seen C compilers that produced byte-code.  They allowed for
a highly interactive developemnt environment.

-- 
Grant Edwards   grant.b.edwardsYow! One FISHWICH coming
  at   up!!
  gmail.com

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

Re: Python-based monads essay (Re: Assignment versus binding)

[Anuradha Laxminarayan]

On Sunday, 9 October 2016 13:18:32 UTC+5:30, Gregory Ewing  wrote:
> Here's the first part of the essay I said I'd write about
> monads:
> 
> http://www.cosc.canterbury.ac.nz/greg.ewing/essays/monads/DemystifyingMonads.html
> 
> Hope it's useful,
> Greg

Thanks, that made a very interesting read.

In Haskell, the type M a -> M b-> M b tells a good deal of the story of seq

In a Pythonic context, continuations seem to be an effective way to carry that 
story.

Small minor haskell suggestions from a pedagodic pov
[related to Ben Finney's suggestion?]

seq f g h = f (\s1 -> g h s1)

better be written as

seq f g x = f (\s1 -> g x s1)

because naming conventions imply that h is function.

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

shadows name from outer scope

[Daiyue Weng]

Hi, I have the following code structure,

def one_func(param1, param2, param3):

process_outcome = {'dict': None}


outcome = another_func(param1, process_outcome, db_host=param2,
funcs_to_run=param3)

PyCharm warns me

Shadows name from outer scope

on every variable here, param1,2,3, process_outcome.

I am wondering how to resolve the issues, and is it vital to have variables
not shadowed?

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

Re: Conventions and requirements for a python module

[Michael Torrie]

On 10/11/2016 08:29 AM, Michael Felt wrote:
>  From reading the python source, and other projects I am looking to 
> patch I see that there is often a file __init__.py, sometimes empty 
> (only comments), sometimes not.
> 
> I have tried looking in what I hope are the "regular" places such as: 
> https://docs.python.org, readthedocs (it took 454 seconds to build 
> something - what did it build, and where do I get it? I was assuming it 
> was "latest documentation" and I even tried the old, no-longer 
> maintained, wiki.
> 
> A search for __init__.py, except for on https://packaging.python.org/ 
> that talks about a setup command to extract the version from __init__.py 
> - I have not been able to find anything on "standards" for packages that 
> are more than a single .py file.
> 
> Probably, I am not looking correctly - however, I do hope someone also 
> notices that finding this is not straight forward for a novice in 
> python. Had I lacked curiosity I would have given up, moved on. Instead 
> - this email.

Yes all this is in the docs:
https://docs.python.org/3/tutorial/modules.html#packages

Also there are links that show up when searching google for "python
packages":
http://www.learnpython.org/en/Modules_and_Packages
http://docs.python-guide.org/en/latest/writing/structure/#packages

Packages are convenient for organizing code. Typically I put code into
__init__.py to organize the package's symbols. In other words whatever
symbols get imported when the package is imported are defined here.
Sometimes I'll import things from sub-modules from within __init__.py
and name and organize them.  Sometimes submodules are left on their own
to be imported separately.  Though the notation "from foo import *" is
discouraged, if a programmer is wont to do that, the package can limit
the damage somewhat by defining the __all__ variable.


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

Conventions and requirements for a python module

[Michael Felt]

From reading the python source, and other projects I am looking to 
patch I see that there is often a file __init__.py, sometimes empty 
(only comments), sometimes not.



I have tried looking in what I hope are the "regular" places such as: 
https://docs.python.org, readthedocs (it took 454 seconds to build 
something - what did it build, and where do I get it? I was assuming it 
was "latest documentation" and I even tried the old, no-longer 
maintained, wiki.


A search for __init__.py, except for on https://packaging.python.org/ 
that talks about a setup command to extract the version from __init__.py 
- I have not been able to find anything on "standards" for packages that 
are more than a single .py file.


Probably, I am not looking correctly - however, I do hope someone also 
notices that finding this is not straight forward for a novice in 
python. Had I lacked curiosity I would have given up, moved on. Instead 
- this email.


In short, I would rather try to "read the manual" and ask questions when 
I get stuck than ask "stupid" questions. That only makes me look bad ;) 
(e.g., in my other thread the idea of using subclasses was made 
frequently. That was something I was considering, but what they are, how 
they are specified, what they achieve rather than guessing that it means 
- intent some related class xxx: lines.


re: project setup: when to use _filename.py - when to use filename.py; 
what is the difference/significance of a sub-directory when "masking" 
complexity, better implementation details, is the goal (i.e., there is 
the API and there are the nitty-gritty implementation details).


The key thing I have learned is that I must not assume that python is 
anything like what I already know/knew. Assume python "does it 
differently" and mistakes maybe fewer.


Thanks for your time and pointers (to links, if not direct advice)

Michael

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

Re: Is it possible Python can distinguish capital letter and small letter in the path of Windows?

[BartC]

On 11/10/2016 13:49, Dennis Lee Bieber wrote:


Unfortunately, Windows is one of the poorest documented OS I've
encountered


The problem is more that there is too much documentation!

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

Re: Python code is compiled before execution

[BartC]

On 11/10/2016 13:35, Pierre-Alain Dorange wrote:

Ben Finney  wrote:


The "small translation into byte-code" *is* compilation.

Don't make the mistake that the only product of "compile" is some CPU
code; that is a foolishly narrow definition.


OK right.
For my part, i differenciate a strict compilation (ie. C) from a
translation into byte-code (ie. Python). From design there was
differences as Python was an interpreted language, not a compiled (AOT).
But as there was only one word, let do with it ;-)

Of course in real language world there was many situation and all kind
of combinaison : strict interpretation, byte-code compilation, JIT
compilation, AOT compilation...

So yes Python compile (bytecode).


I use 'byte-code compiler' and 'native-code compiler' when the 
distinction is important.


Python is not really suited for AOT native-code compilation. Here I 
might just say CPython if I'm assuming a normal byte-code compiler and 
byte-code interpreter model.


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

Re: Is it possible Python can distinguish capital letter and small letter in the path of Windows?

[eryk sun]

On Tue, Oct 11, 2016 at 10:34 AM,   wrote:
> I have two files in the Q:\lib directory:
>
> Q:\lib>dir
> 2007/03/11 AM 08:025,260  lib_MARK.so
> 2007/03/11 AM 08:024,584  lib_mark.so
>
> Under Python 3.4.4 I got:
>
 f = open('lib_MARK.so', 'br')
 data = f.read()
 f.close()
 len(data)
> 4584
>
> I know Windows won't, but can Python make it true?

Windows can do case-sensitive file operations, but it's not easy in
Python. You have to use the Windows API directly via _winapi, ctypes,
or PyWin32, depending on your needs.

First, disable the registry setting that forces the kernel's object
manager to be case insensitive for operations on its own object types
(i.e. object directories and symlinks) and I/O object types (e.g.
devices, files). Here's a .reg file to do this:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]
"obcaseinsensitive"=dword:

You have to reboot after making this change.

This alone doesn't make the Windows API case sensitive, but it does
enable individual CreateFile calls to be case sensitive, via the POSIX
semantics flag. Once you have a handle for the target file or
directory, you can accomplish most file operations via
GetFileInformationByHandleEx [1] and SetFileInformationByHandle [2].

[1]: https://msdn.microsoft.com/en-us/library/aa364953
[2]: https://msdn.microsoft.com/en-us/library/aa365539

Here's a basic example, based on your example with "lib_mark.so" and
"lib_MARK.so":

import os
import _winapi

GENERIC_READ = 0x8000
GENERIC_WRITE = 0x4000
OPEN_EXISTING = 3
FILE_SHARE_READ = 1
FILE_SHARE_WRITE = 2
FILE_SHARE_DELETE = 4
FILE_FLAG_POSIX_SEMANTICS = 0x00100

def create_file(path,
access=GENERIC_READ | GENERIC_WRITE,
sharing=FILE_SHARE_READ | FILE_SHARE_WRITE,
disposition=OPEN_EXISTING,
flags=0):
sharing |= FILE_SHARE_DELETE
flags |= FILE_FLAG_POSIX_SEMANTICS
return _winapi.CreateFile(path, access, sharing, 0,
  disposition, flags, 0)

>>> os.listdir('.')
['lib_MARK.so', 'lib_mark.so']

>>> h1 = create_file('lib_MARK.so')
>>> len(_winapi.ReadFile(h1, 1)[0])
5260

>>> h2 = create_file('lib_mark.so')
>>> len(_winapi.ReadFile(h2, 1)[0])
4584
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python code is compiled before execution

[Pierre-Alain Dorange]

Ben Finney  wrote:

> The "small translation into byte-code" *is* compilation.
> 
> Don't make the mistake that the only product of "compile" is some CPU
> code; that is a foolishly narrow definition.

OK right.
For my part, i differenciate a strict compilation (ie. C) from a
translation into byte-code (ie. Python). From design there was
differences as Python was an interpreted language, not a compiled (AOT).
But as there was only one word, let do with it ;-)

Of course in real language world there was many situation and all kind
of combinaison : strict interpretation, byte-code compilation, JIT
compilation, AOT compilation...

So yes Python compile (bytecode).

-- 
Pierre-Alain Dorange   Moof 

Ce message est sous licence Creative Commons "by-nc-sa-2.0"

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

Python Shell in Russian exists/possible??

[Андрей Логунов]

I need the Python Shell for use in education (turtle graphics, etc.), but the 
UI must be localized in the Russian language. The question is if it's at all 
possible to feed the strings in or rebuild it or...
-- 
https://mail.python.org/mailman/listinfo/python-list

Is it possible Python can distinguish capital letter and small letter in the path of Windows?

[jfong]

I have two files in the Q:\lib directory:

Q:\lib>dir
2007/03/11 AM 08:025,260  lib_MARK.so
2007/03/11 AM 08:024,584  lib_mark.so

Under Python 3.4.4 I got:

>>> f = open('lib_MARK.so', 'br')
>>> data = f.read()
>>> f.close()
>>> len(data)
4584

I know Windows won't, but can Python make it true?

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

Re: How to process syntax errors

[Marko Rauhamaa]

Chris Angelico :

>>> > You're right, except that Python is never compiled, it was just
>>> > checked for syntax error before interpreting code.
>>>
>>> https://docs.python.org/3/library/functions.html#compile
>>>
>>> It's compiled.
>>
>> Using this function, the code is "compiled".
>> I do not think this function is often used and most python project
>> simply use the interpreter (which do a small translation into
>> byte-code to be faster and check syntax error before running
>> interpretation).
>
> When you import, the same form of compilation is done. It always
> happens. Python does not execute your raw source code - it'd be too
> inefficient.

There's no clear line between compilation and interpretation. You have
the source code and the execution semantics. All kinds of opportune
transformations can take place before the execution, after the
execution, during the execution etc as long as the correct semantics are
obeyed.


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

Python code is compiled before execution (was: How to process syntax errors)

[Ben Finney]

pdora...@pas-de-pub-merci.mac.com (Pierre-Alain Dorange) writes:

> Chris Angelico  wrote:
>
> > https://docs.python.org/3/library/functions.html#compile
> > 
> > [Python code is] compiled.
>
> Using this function, the code is "compiled".

You have it backward: Python code is compiled. That's what the Python
runtime requires. It often happens automatically, but it happens for all
Python code that gets executed.

What that function does is allow you to *separately* compile the Python
code.

> I do not think this function is often used and most python project
> simply use the interpreter (which do a small translation into byte-code
> to be faster and check syntax error before running interpretation).

The “small translation into byte-code” *is* compilation.

Don't make the mistake that the only product of “compile” is some CPU
code; that is a foolishly narrow definition.

(Good sigmonster, have a cookie.)

-- 
 \  “[I]t is impossible for anyone to begin to learn that which he |
  `\thinks he already knows.” —Epictetus, _Discourses_ |
_o__)  |
Ben Finney

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

Re: How to process syntax errors

[Chris Angelico]

On Tue, Oct 11, 2016 at 7:02 PM, Pierre-Alain Dorange
 wrote:
> Chris Angelico  wrote:
>
>> >> Yes and no. Syntax errors are detected when the script is compiled, so
>> >> you can't do something like this:
>> >
>> > You're right, except that Python is never compiled, it was just checked
>> > for syntax error before interpreting code.
>>
>> https://docs.python.org/3/library/functions.html#compile
>>
>> It's compiled.
>
> Using this function, the code is "compiled".
> I do not think this function is often used and most python project
> simply use the interpreter (which do a small translation into byte-code
> to be faster and check syntax error before running interpretation).

When you import, the same form of compilation is done. It always
happens. Python does not execute your raw source code - it'd be too
inefficient.

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

Re: How to process syntax errors

[Pierre-Alain Dorange]

Chris Angelico  wrote:

> >> Yes and no. Syntax errors are detected when the script is compiled, so
> >> you can't do something like this:
> >
> > You're right, except that Python is never compiled, it was just checked
> > for syntax error before interpreting code.
> 
> https://docs.python.org/3/library/functions.html#compile
> 
> It's compiled.

Using this function, the code is "compiled".
I do not think this function is often used and most python project
simply use the interpreter (which do a small translation into byte-code
to be faster and check syntax error before running interpretation).

> 
> >> However, you can catch this at some form of outer level. If you're
> >> using exec/eval to run the code, you can guard that:
> >
> > Your solution are OK, but that's not very "pythonic".
> >
> > Python was not design to be used in such a way (intercepting syntax
> > error). There was hack to made somthing like requested but that only a
> > hack and should not be used in real world.
> 
> The error is raised as an exception, which means it is most definitely
> meant to be able to be caught.

Using compile() function yes.

So yes there is a way to check "syntax error" before executing code
(using compile function and exceptions) but it was not standard, nor
widely used... It was still a hack for me, but perhaps i misunderstood
or misinterpret.


-- 
Pierre-Alain Dorange   Moof 

Ce message est sous licence Creative Commons "by-nc-sa-2.0"

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