Re: How to handle attachments passed via Postfix

[Burak Arslan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 10/13/15 00:52, Anthony Papillion wrote:
>> Check out the email.parser module, or the convenience function
>> > email.message_from_string - you should be able to get at the
>> > different parts (including attachments) from there.
>> >
> Many thanks! Checking it out now. Sounds like exactly what I'm looking
> for.

Also have a look at flanker (https://github.com/mailgun/flanker)
basically doing the same thing.

Here's why it exists:
https://github.com/mailgun/flanker/blob/master/docs/User%20Manual.md#rationale

Best,
Burak
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWHKzpAAoJEDzeDArrSnh8eKwQAJJ1odTXgJkVi4LgmxhN/CLR
jWdGCGdpIds1WNJ2iwcagF1N57oU3Lfq1xuTmF7GtCbRyL5/O9Tsjmge+xw8jzDQ
va/ge2keR2LTRlJd/XAYmQSx8ArGq/2K/hG/xNbzMjMhDo49ZQXenzGAZxCnMPcj
x5i1Op/PeKBNz/lTyHvkMPNubtc5XWaKo2U9QxaA151A/jNCJPNQ0jpezkjKdHlo
2PEYNgoqU5ioF+wQ6bHwk/QCgIYINO3Spm0MqE+49qVnOhDl/LabnT5ckpGMOn4N
mMPbSWIKNMOs+ulFScy2lV6yBFPi/eniZF4S7V1osxiPxu/N1X1fK92gljw31JQF
tkumMBV+ql2nuv288zPPJG3O8YUvUug/v2OJewIvjPr5eBabcwDYZHdoW8oPBBuU
DGVaJPynzUNvm1SaTE+/w7Baa19XIB+IqvYw42Ey4xoZQgr5T10h7ipwnpcNCWwy
7TQ5MdxhIeR1iiV9ofF2gxLWkE8bWJJ0eCBcOFvgXbUWbsdKsp+WqHHuXBjRedvI
1PGWJWBd411hpDnJc0vVVW5zqJqGr4MKkxEVh9K5T0RLcaUeXlQEMWWzl6n2/3KX
Nv9jNQ5T7raiBRgXt8/DXBLTreq9FzCxpRR3HMUeoZo2If2bkQ983tK2U8IxCxoE
hTQsYzrEFEiw37ypo9G2
=5gjA
-END PGP SIGNATURE-

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

Re: Strong typing implementation for Python

[Todd]

On Oct 13, 2015 2:11 AM, "Steven D'Aprano"  wrote:
>
> On Tue, 13 Oct 2015 04:20 am, Marko Rauhamaa wrote:
>
> > As for managing complexity, many people believe static typing is a
> > crucial tool. I disagree. Static typing adds vast amounts of noise to
> > the code.
>
> Only if you are stuck in the 1970s. And even then, it is not always noise,
> type declarations or annotations often make useful documentation.
>
> Consider the following piece of code:
>
> def addone(x):
> return x + 1
>
>
> The human programmer reading that can trivially infer that x must be a
> number (or at least something which supports numeric addition). So can the
> compiler. In a strongly typed language with no numeric promotion, the
> compiler can infer that x must be an int. In a language with numeric
> promotion, it can infer that x must be an int or float.

Or a decimal, complex number, numpy array, any one of a dozen or so pandas
classes, any one of the dozen or so units classes, sympy variable, etc...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[m]

W dniu 13.10.2015 o 03:35, Michael Torrie pisze:
> On 10/12/2015 06:07 PM, Steven D'Aprano wrote:
>> > Where is the "vast amounts of noise" added to the code?
> Well in Java code for one.  No wonder they require auto-completion.
> Java class-based namespaces must be a nightmare to work with. 

IMHO mainly because their naming convention. They just love typing long
names. If they used named like in python, that "vast amount of noise
added to code" would be just "a bit noise added to code"

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

Python not working on my system

[Cinto Llach]

I'm sending you this email, as I'm having problems trying to install and use
Python.

 

I've been tryng to install Python on one System :

HP Intel Core 2 Duo 4300, 1,8 GHz

2 Gb RAM

Windows XP Professional SP 3

 

And I've got the following screens, with no visible Command Buttons. I've
been able to proceed by blind testing in the forms ...

 



 

Setup was successful ...

 



 

It appears in Start Menu ...

 



 

But when trying to launch pythonw.exe :

 



 

Or python.exe :

 



 

And when uninstalling, the form show no buttons ...

 



 

But after finding the locations to click ...

 



 

I will thank you if you can provide any help.

 

Best wishes.

 

Cinto Llach

cll...@outlook.com  

cll...@email.com  

 

034 622401038

 

Barcelona

 

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

Re: Python not working on my system

[Mathew Carrick]

Hi Cinto,

Python 3.5 does not work on Windows XP. Can you use Python 3.4 instead?

Best,
Mathew Carrick

On Tue, Oct 13, 2015 at 12:10 AM, Cinto Llach  wrote:

> I’m sending you this email, as I’m having problems trying to install and
> use Python.
>
>
>
> I’ve been tryng to install Python on one System :
>
> HP Intel Core 2 Duo 4300, 1,8 GHz
>
> 2 Gb RAM
>
> Windows XP Professional SP 3
>
>
>
> And I’ve got the following screens, with no visible Command Buttons. I’ve
> been able to proceed by blind testing in the forms ...
>
>
>
>
>
> Setup was successful ...
>
>
>
>
>
> It appears in Start Menu ...
>
>
>
> [image: cid:image003.png@01D10513.21E3F4C0]
>
>
>
> But when trying to launch pythonw.exe :
>
>
>
>
>
> Or python.exe :
>
>
>
>
>
> And when uninstalling, the form show no buttons ...
>
>
>
>
>
> But after finding the locations to click ...
>
>
>
>
>
> I will thank you if you can provide any help.
>
>
>
> Best wishes.
>
>
>
> Cinto Llach
>
> cll...@outlook.com
>
> cll...@email.com
>
>
>
> 034 622401038
>
>
>
> Barcelona
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Some Help getting started

[Laura Creighton]

In a message of Mon, 12 Oct 2015 16:58:40 -0600, Ian Kelly writes:
>Just saying that it doesn't work doesn't help us help you. What
>precisely have you tried, and what was the error that you got when you
>tried it?

What Ian said.  Also what python version are you using and what OS?

Laura

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

Re: Strong typing implementation for Python

[Laura Creighton]

In a message of Mon, 12 Oct 2015 19:35:57 -0600, Michael Torrie writes:
>On 10/12/2015 06:07 PM, Steven D'Aprano wrote:
>> Where is the "vast amounts of noise" added to the code?
>
>Well in Java code for one.  No wonder they require auto-completion.
>Java class-based namespaces must be a nightmare to work with.  That and
>all the over-use of design patterns that Java libraries love to do,
>though in fairness Java requires a certain amount of boilerplate to do
>things like singletons and factories, whereas Python can often just use
>a module.

When Design Patterns were new, the 2 of the first books to come out were
'Design Patterns'[1995] which was C++ focused, and the 'Design Patterns
Smalltalk Companion'[1998].  If you read the two of them, side by
side (as DPSTC asks you to) you will be struct by how little of the
C++ code is about 'here is the pattern I want to implement' and how
much is 'here is what to do to bash the C++ type system into
submission' -- to the point where a couple of DP are files, in the
Smalltalk version as 'for Smalltalk this is only a few lines of code,
not enough to really be a pattern (and I bet you do this all the time
without thinking that you were using a Design pattern, don't you?)'.
The Smalltalk versions are all so much sorter.  And Smalltalk, like
Python is a strongly and dynamically typed langauge.

Thus it is no wonder that the DP get used more than they need to in
the java world.  No matter what you write you will have to write the
'and then get it past the type checking' part, and grabbing a
well-tested one of those saves you from a lot of bugs, even if
you have to take and overly-heavy and complicated DP to go along
with it.

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

Re: How to handle attachments passed via Postfix

[Anthony Papillion]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On October 13, 2015 2:04:09 AM CDT, Burak Arslan  
wrote:
>
>
>On 10/13/15 00:52, Anthony Papillion wrote:
>>> Check out the email.parser module, or the convenience function
>>> > email.message_from_string - you should be able to get at the
>>> > different parts (including attachments) from there.
>>> >
>> Many thanks! Checking it out now. Sounds like exactly what I'm
>looking
>> for.
>
>Also have a look at flanker (https://github.com/mailgun/flanker)
>basically doing the same thing.
>
>Here's why it exists:
>https://github.com/mailgun/flanker/blob/master/docs/User%20Manual.md#rationale

Thanks Burak!I've just had a look at it and it looks pretty amazing.  I 
particularly like the speed incest and smaller memory footprint.  Thanks for 
pointing me here!

Anthony

- --
Phone:  +1.845.666.3312
Skype:   CajunTechie
SIP/VoIP:  17772471...@in.callcentric.com
PGP Key:   0x53B04B15
Fingerprint:   C5CE  E687  DDC2  D12B 9063  56EA  028A DF74  53B0  4B15

-BEGIN PGP SIGNATURE-
Version: APG v1.1.1

iQJJBAEBCgAzBQJWHM+8LBxBbnRob255IFBhcGlsbGlvbiA8YW50aG9ueUBjYWp1
bnRlY2hpZS5vcmc+AAoJEAKK33RTsEsVmCQP/3KYdbTjyXW33BkCalagLosJC6os
xGVggx1TB8aK0QFDAJoVRAKZ7nn9AV75VC/+Y9qIVJyMWS9GQICMhU29NeSJ7Uao
DL6XqROpOy8hl9Mnu+e5c0TwL9SI2oKeOwRqxwJVVWq9kM/og99ryfKOaNIVBoV4
32gHHYqjEx/zXlmYTL0gTbYbK/LJyVlmfVYWXjdvb7QWsv8g+5NyRUpqKrx+Pvvs
YPhtfQ/ltgo7NxSU2e3hNWp91F29J840d82jvHVqPEMpAHVikFBYAD8B1fkeLvBi
z9x5mQfGdReLlnUngbCcJJ0/6Vwla5LeK2nvAJuMofjy2NKCS91arLmp5wIgWz7P
CMSep1Lt1Nhd1PRKMF0uXFMZ1i7cC7BzalyY6WJHnFBryLh0uxrEMH2ma1ZR+d7W
PgcMo4nmB9ECIbZAGQE5p46QJ08op8E5GnrtRfOlcCpJIYLT2CEIg4cSz14cPm8f
0mCP7iMz3B5CeASTnfJ425mTczHVgtd20FpiRNUh58JvoSlLL0nmRaL4yJfBlC+t
u75UsNxknWPsy3tDCDs2U+gdo0vrla0Ld5iy2i38oiJ0a9KBeUiLrJd7AJi4fQft
BPJHDdRbUBXnpkb7VyPLF7ftxEVvI/XxJr8NY99DU/hfexsOiY/49YFdj783GxDk
FuzU9Vmd1HAeou0T
=JVUd
-END PGP SIGNATURE-

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

ANN: Python Meeting Düsseldorf - 21.10.2015

[eGenix Team: M.-A. Lemburg]

[This announcement is in German since it targets a local user group
 meeting in Düsseldorf, Germany]



ANKÜNDIGUNG

 Python Meeting Düsseldorf

 http://pyddf.de/

   Ein Treffen von Python Enthusiasten und Interessierten
in ungezwungener Atmosphäre.

  Mittwoch, 21.10.2015, 18:00 Uhr
  Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk
Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf

Diese Nachricht ist auch online verfügbar:
http://www.egenix.com/company/news/Python-Meeting-Duesseldorf-2015-10-21



NEUIGKEITEN

 * Bereits angemeldete Vorträge:

   Matthias Endler:
   "Writing a fuzzy receipt parser in Python using tesseract"

   Marc-Andre Lemburg:
   "Untwisting Mersenne Twister: Python's Zufallszahlengenerator"
   "Portierung von mxDateTime auf Python 3"

   Weitere Vorträge können gerne noch angemeldet werden: i...@pyddf.de

 * Startzeit und Ort:

   Wir treffen uns um 18:00 Uhr im Bürgerhaus in den Düsseldorfer
   Arcaden.

   Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad
   und befindet sich an der Seite der Tiefgarageneinfahrt der
   Düsseldorfer Arcaden.

   Über dem Eingang steht ein großes “Schwimm’'in Bilk”
   Logo. Hinter der Tür direkt links zu den zwei Aufzügen,
   dann in den 2. Stock hochfahren. Der Eingang zum Raum 1
   liegt direkt links, wenn man aus dem Aufzug kommt.

   Google Street View: http://bit.ly/11sCfiw



EINLEITUNG

Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in
Düsseldorf, die sich an Python Begeisterte aus der Region wendet:

 * http://pyddf.de/

Einen guten Überblick über die Vorträge bietet unser YouTube-Kanal,
auf dem wir die Vorträge nach den Meetings veröffentlichen:

 * http://www.youtube.com/pyddf/

Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld,
in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf:

 * http://www.egenix.com/
 * http://www.clark-consulting.eu/



PROGRAMM

Das Python Meeting Düsseldorf nutzt eine Mischung aus Open Space
und Lightning Talks, wobei die Gewitter bei uns auch schon mal
20 Minuten dauern können ;-).

Lightning Talks können vorher angemeldet werden, oder auch
spontan während des Treffens eingebracht werden. Ein Beamer mit
XGA Auflösung steht zur Verfügung. Folien bitte als PDF auf USB
Stick mitbringen.

Lightning Talk Anmeldung bitte formlos per EMail an i...@pyddf.de



KOSTENBETEILIGUNG

Das Python Meeting Düsseldorf wird von Python Nutzern für Python
Nutzer veranstaltet. Um die Kosten zumindest teilweise zu
refinanzieren, bitten wir die Teilnehmer um einen Beitrag
in Höhe von EUR 10,00 inkl. 19% Mwst, Schüler und Studenten
zahlen EUR 5,00 inkl. 19% Mwst.

Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen.



ANMELDUNG

Da wir nur für ca. 20 Personen Sitzplätze haben, möchten wir
bitten, sich per EMail anzumelden. Damit wird keine Verpflichtung
eingegangen. Es erleichtert uns allerdings die Planung.

Meeting Anmeldung bitte formlos per EMail an i...@pyddf.de



WEITERE INFORMATIONEN

Weitere Informationen finden Sie auf der Webseite des Meetings:

http://pyddf.de/

Mit freundlichen Grüßen,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Oct 13 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/

2015-10-21: Python Meeting Duesseldorf ...  8 days to go

: Try our mxODBC.Connect Python Database Interface for free ! ::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
-- 
https://mail.python.org/mailman/listinfo/python-list

User defined generic types and collections.abc

[Martí Congost]

I have a package that defines a variety of collections based on the ABCs
provided by collections.abc (Mapping, Sequence, etc). I wanted to take
advantage of the type hinting facilities introduced in Python 3.5, and I'm
having doubts as to what would be the best way to go about it.

Lets take one of these classes as an exemple; until now, I had something
resembling this:

  from collections.abc import Mapping

  class MyMapping(Mapping):
...

To turn this into a generic type, the documentation (
https://www.python.org/dev/peps/pep-0484/#arbitrary-generic-types-as-base-classes)
would seem to suggest doing something like this:

  from typing import Generic, Hashable, TypeVar, Mapping

  K = TypeVar("K", bound=Hashable)
  V = TypeVar("V")

  class MyMapping(Mapping[K, V]):
  ...

But this poses two problems:

- The class looses all the mixin methods from collections.abc.Mapping. I
could deal with this by implementing them myself, but that would defeat
part of the purpose of using ABCs in the first place.

- isinstance(MyMapping(), collections.abc.Mapping) returns False. Also,
trying to call collections.abc.Mapping.register(MyMapping) to work around
this raises a RuntimeError ("Refusing to create an inheritance cycle").

My first attempt to solve these problems was to go back to extending
collections.abc.Mapping:

  from typing import Generic, Hashable, TypeVar
  from collections.abc import Mapping

  K = TypeVar("K", bound=Hashable)
  V = TypeVar("V")

  class MyMapping(Mapping[K, V]):
  ...

But that doesn't work, as collections.abc.Mapping is not a generic type and
does not support the subscription operator. So I tried this:

from typing import Generic, Hashable, TypeVar, Mapping
from collections.abc import Mapping as MappingABC

  K = TypeVar("K", bound=Hashable)
  V = TypeVar("V")

  class MyMapping(MappingABC, Mapping[K, V]):
  ...

But this smells fishy. The imports and aliasing are cumbersome, the
resulting class has a tortuous MRO, and the mix-in methods provided by the
ABC won't have typing information...

So what is the preferred way to declare a custom generic type based on a
collection ABC?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[Marko Rauhamaa]

Laura Creighton :

> When Design Patterns were new, the 2 of the first books to come out
> were 'Design Patterns'[1995] which was C++ focused, and the 'Design
> Patterns Smalltalk Companion'[1998]. If you read the two of them, side
> by side (as DPSTC asks you to) you will be struct by how little of the
> C++ code is about 'here is the pattern I want to implement' and how
> much is 'here is what to do to bash the C++ type system into
> submission' -- to the point where a couple of DP are files, in the
> Smalltalk version as 'for Smalltalk this is only a few lines of code,
> not enough to really be a pattern (and I bet you do this all the time
> without thinking that you were using a Design pattern, don't you?)'.
> The Smalltalk versions are all so much sorter. And Smalltalk, like
> Python is a strongly and dynamically typed langauge.
>
> Thus it is no wonder that the DP get used more than they need to in
> the java world. No matter what you write you will have to write the
> 'and then get it past the type checking' part, and grabbing a
> well-tested one of those saves you from a lot of bugs, even if you
> have to take and overly-heavy and complicated DP to go along with it.

Great post!

A few years back I programmed in Java. I literally had to write (or
generate) 2,000 lines of code to satisfy the structural requirements
(interfaces, method stubs, javadocs, ...) before the code actually did
anything.


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

sorry for all the typos

[Laura Creighton]

re-reading what I wrote after Marko quoted it, I see an
unacceptable level of typos and other sentence structure
errors.  I have eyedrops in my eyes today.  I really cannot 
read what I type well enough.  

Amusing that my fingers find 'struct' a more reasonable thing to
type than 'struck', (to me at any rate) ...

Laura


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

I have this programme (annotated) I want allow it to run more than once any tips or even better python code. :)

[abbasmo]

import time
#this is so that i can set a timer
print ("only print numbers as your answers (Round all numbers up):   ")
time.sleep(2)
#this is to let the person know what format to write it in#
answer = input ("enter the height of the room walls between 2 to 6 metres:   ")
#this is the first input to understand what the client wants#
print (answer)
#this is to let the client know what value they have put in to see if they have 
made a mistake#
while answer == range(2,6):
Q1
#this lets the programme know which figures are acceptable#
Q1 = input("enter length of room walls between 1 to 25 metres: ")
#this the second question that is chosen#
print (Q1)
#This is again to let the client know what number they have inserted in case 
they have made an error
while Q1 == range(1,25):
Q2
#this is to let the programme know the numbers that are acceptable#
Q2 = input("choose the price of paint that you want. Luxury = 175 Standard cost 
100 Economy = 45 ALL PRICES MULTIPLIED BY 100  : ")
#this is the final question that is asked#
print (Q2)
#this the final indication of what the client has inserted into the equasion#



y = (int(answer) * int(Q1)* int(Q2))
#This tells the programme to multiply the numbers together#
print (y/100 + 0.5)
#this is because the programme only accepts whole numbers and to get the real 
value i needed to devide by 100
time.sleep(25)

#problem with this programme is that it allows any number to be placed in the 
system and also that it stops straight away hence the timer. if you have any 
advice I would love to hear#
-- 
https://mail.python.org/mailman/listinfo/python-list

Extended functions in embedded code

[Ervin Hegedüs]

Hello there,

I'm interesting for the embeding of Python code - the examples and docs are
very helpfully. The main code, which embeds the Python interpreter, had
written in C. There are several functions, what I have to use in embedded
(Python) code, so I must to write them as Python extension.

That's no problem - I found a solution for that, I don't need to made (and
I don't _want_) a separated .so file (a new Python module): the extension
in same C source, where the embedded code exists, like this:

#include 
#include 

/* python mymodule */
static PyObject*
mymodule_usleep(PyObject *self, PyObject *args)
{
...
}

...
static PyMethodDef mymodule_methods[] = {
{"usleep",mymodule_usleep,METH_VARARGS,mymodule_usleep_doc},
{NULL, NULL}
};

PyMODINIT_FUNC
initmymodule(void)
{
(void) Py_InitModule("mymodule", mymodule_methods);
}

/* python mymodule */


/* python embedding */
void foo() {
Py_Initialize();
initmymodule();

Py_Finalize();
}

/* python embedding */


Then I have a Python file, which the code above calls:

import mymodule

def bar(d)
do_something()
mymodule.usleep(1)
return something


Just my "2 cents" question: is there any way to make the extension without
"import" keyword? Or is there a way to leave that?


Thanks,


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

dont know if it sent sorry if it has

[abbasmo]

import time
#this is so that i can set a timer
print ("only print numbers as your answers (Round all numbers up):   ")
time.sleep(2)
#this is to let the person know what format to write it in#
answer = input ("enter the height of the room walls between 2 to 6 metres:   ")
#this is the first input to understand what the client wants#
print (answer)
#this is to let the client know what value they have put in to see if they have 
made a mistake#
while answer == range(2,6):
Q1
#this lets the programme know which figures are acceptable#
Q1 = input("enter length of room walls between 1 to 25 metres: ")
#this the second question that is chosen#
print (Q1)
#This is again to let the client know what number they have inserted in case 
they have made an error
while Q1 == range(1,25):
Q2
#this is to let the programme know the numbers that are acceptable#
Q2 = input("choose the price of paint that you want. Luxury = 175 Standard cost 
100 Economy = 45 ALL PRICES MULTIPLIED BY 100  : ")
#this is the final question that is asked#
print (Q2)
#this the final indication of what the client has inserted into the equasion#



y = (int(answer) * int(Q1)* int(Q2))
#This tells the programme to multiply the numbers together#
print (y/100 + 0.5)
#this is because the programme only accepts whole numbers and to get the real 
value i needed to devide by 100
time.sleep(25)

#problem with this programme is that it allows any number to be placed in the 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[Bartc]

On 13/10/2015 11:42, Marko Rauhamaa wrote:


A few years back I programmed in Java. I literally had to write (or
generate) 2,000 lines of code to satisfy the structural requirements
(interfaces, method stubs, javadocs, ...) before the code actually did
anything.


And this is the recommended language if you want to code apps for 
Android. (Actually I don't think it's that easy to use another language 
of your choice.)


Who decides these things?

--
Bartc


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

Re: Extended functions in embedded code

[Laura Creighton]

Are you looking for this:?
https://docs.python.org/3.5/library/runpy.html
or maybe this:?
https://docs.python.org/3.5/library/importlib.html#importlib.import_module
Or is your real problem 'I don't have a filesystem'?

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

Re: Strong typing implementation for Python

[Laura Creighton]

In a message of Tue, 13 Oct 2015 13:31:56 +0100, Bartc writes:
>On 13/10/2015 11:42, Marko Rauhamaa wrote:
>
>> A few years back I programmed in Java. I literally had to write (or
>> generate) 2,000 lines of code to satisfy the structural requirements
>> (interfaces, method stubs, javadocs, ...) before the code actually did
>> anything.
>
>And this is the recommended language if you want to code apps for 
>Android. (Actually I don't think it's that easy to use another language 
>of your choice.)
>
>Who decides these things?
>-- 
>Bartc

Start using kivy and vote with your feet!
http://kivy.org/#home

Laura

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

Re: Strong typing implementation for Python

[Steven D'Aprano]

On Tue, 13 Oct 2015 06:55 pm, Todd wrote:

> On Oct 13, 2015 2:11 AM, "Steven D'Aprano"  wrote:

>> Consider the following piece of code:
>>
>> def addone(x):
>> return x + 1
>>
>>
>> The human programmer reading that can trivially infer that x must be a
>> number (or at least something which supports numeric addition). So can
>> the compiler. In a strongly typed language with no numeric promotion, the
>> compiler can infer that x must be an int. In a language with numeric
>> promotion, it can infer that x must be an int or float.
> 
> Or a decimal, complex number, numpy array, any one of a dozen or so pandas
> classes, any one of the dozen or so units classes, sympy variable, etc...

I knew my over-simplification would get me in trouble...

Firstly, if we're talking about Python specifically, the compiler won't
actually infer anything (see PEP 484, which "assumes the existence of a
separate off-line type checker which users can run over their source code
voluntarily"). It is up to the external type checker (or linter, IDE,
documentation generator, refactoring tool, etc) to perform any type checks.

Secondly, what the tool actually infers will depend on the tool. I would
expect that a basic type checker (say, in a text editor) will infer that x
is an int or float only. A more powerful checker might infer the Number ABC
(Abstract Base Class). A specialist checker might even know about numpy,
pandas, units and sympy, but I wouldn't expect a general-purpose type
checker to infer them.

If the programmer cares about such specialist types, then she can easily add
type hints to supplement the checker's type inference, or the checker
itself may be configurable. That's a *quality of implementation* detail.

The beauty of *gradual typing* is that you don't have to care about every
possible class in the entire universe of Python code, only about the
classes you actually care about in the parts of your code you choose to
type check.

http://wphomes.soic.indiana.edu/jsiek/what-is-gradual-typing/

Because the Python interpreter itself doesn't care about the compile-time
type checking, if the checker gets in your way, you can just *not run it*.
I also expect that good checkers will include directives to skip sections
of code, so you can include annotations as documentation while still
silencing over-strict or incorrect compile-time type errors. (Runtime type
errors will still occur as normal.)



-- 
Steven

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

Strict comparisons in Python 2

[Steven D'Aprano]

In Python 3, comparisons between arbitrary types raise TypeError:

py> None < 2
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unorderable types: NoneType() < int()


In Python 2, that same comparison will arbitrarily return True or False,
according to some implementation-dependent rule.

Is there some way to force the Python 3 rules into Python 2? Something like
a __future__ import?



-- 
Steven

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

Re: Strict comparisons in Python 2

[Ian Kelly]

On Oct 13, 2015 7:48 AM, "Steven D'Aprano"  wrote:
>
> In Python 3, comparisons between arbitrary types raise TypeError:
>
> py> None < 2
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: unorderable types: NoneType() < int()
>
>
> In Python 2, that same comparison will arbitrarily return True or False,
> according to some implementation-dependent rule.
>
> Is there some way to force the Python 3 rules into Python 2? Something
like
> a __future__ import?

You couldn't do this with a __future__ import because those must be
confined to the importing module and are therefore generally limited to
syntax changes. It may be a good candidate for the six library, but I don't
see any existing support there for it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Extended functions in embedded code

[Ervin Hegedüs]

Hi,


On Tue, Oct 13, 2015 at 02:51:21PM +0200, Laura Creighton wrote:
> Are you looking for this:?
> https://docs.python.org/3.5/library/runpy.html

I think I'm not - I'm afraid, the runpy modul wasn't developed
for me, for this reason.

> or maybe this:?
> https://docs.python.org/3.5/library/importlib.html#importlib.import_module

I think this is just an "alias" of the standard import.

> Or is your real problem 'I don't have a filesystem'?

no, I have filesystem. I help to contribute a software, which had
written in C. The configuration schema is very simple, there are
several keywords, but not all required function could be
configure with them. Python would be a good choice, but the
users aren't programmers in most cases. I just don't want to
start the documentation, that

"Make a Python script like this:

import mymodul

"

and nobody knows, why is it require, because there isn't any
module with this name.


As I wrote, that's just my 2-cents question, not a critical issue
- it could be better to know, is it possible or not. That's all :)
 


a.

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

Re: Extended functions in embedded code

[Chris Angelico]

On Wed, Oct 14, 2015 at 1:59 AM, Ervin Hegedüs  wrote:
> no, I have filesystem. I help to contribute a software, which had
> written in C. The configuration schema is very simple, there are
> several keywords, but not all required function could be
> configure with them. Python would be a good choice, but the
> users aren't programmers in most cases. I just don't want to
> start the documentation, that
>
> "Make a Python script like this:
>
> import mymodul
>
> "
>
> and nobody knows, why is it require, because there isn't any
> module with this name.

Sounds to me like the easiest way would be to inject into the
builtins. You should be able to import the builtins module from your C
code, and then stuff some extra attributes into it; they'll be
automatically available to the script, same as the "normal" built-in
names like int, super, and ValueError.

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

Re: Strict comparisons in Python 2

[Random832]

Ian Kelly  writes:
> You couldn't do this with a __future__ import because those must be
> confined to the importing module and are therefore generally limited
> to syntax changes.

In principle, it could be a syntax change to the < operator (etc) to
cause it to try to call a different method first, same as division and
the / operator. That'd be a bit heavyweight to do this late in the
Python 2 cycle though.

What might be nice would be a general way to pass in lexical context
information to the methods called to implement operators.

> It may be a good candidate for the six library, but
> I don't see any existing support there for it.

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

Re: Extended functions in embedded code

[Ervin Hegedüs]

Hi Chris,

On Wed, Oct 14, 2015 at 02:05:43AM +1100, Chris Angelico wrote:
> On Wed, Oct 14, 2015 at 1:59 AM, Ervin Hegedüs  wrote:
> > no, I have filesystem. I help to contribute a software, which had
> > written in C. The configuration schema is very simple, there are
> > several keywords, but not all required function could be
> > configure with them. Python would be a good choice, but the
> > users aren't programmers in most cases. I just don't want to
> > start the documentation, that
> >
> > "Make a Python script like this:
> >
> > import mymodul
> >
> > "
> >
> > and nobody knows, why is it require, because there isn't any
> > module with this name.
> 
> Sounds to me like the easiest way would be to inject into the
> builtins. You should be able to import the builtins module from your C
> code, and then stuff some extra attributes into it; they'll be
> automatically available to the script, same as the "normal" built-in
> names like int, super, and ValueError.

well, sounds good - this solution would be right for me. Could
you show me a good example and/or documentation about this? I've
looked up, but "python extend built-in module" is may be too
simple expression :).


a.

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

Re: Extended functions in embedded code

[Chris Angelico]

On Wed, Oct 14, 2015 at 2:29 AM, Ervin Hegedüs  wrote:
>>
>> Sounds to me like the easiest way would be to inject into the
>> builtins. You should be able to import the builtins module from your C
>> code, and then stuff some extra attributes into it; they'll be
>> automatically available to the script, same as the "normal" built-in
>> names like int, super, and ValueError.
>
> well, sounds good - this solution would be right for me. Could
> you show me a good example and/or documentation about this? I've
> looked up, but "python extend built-in module" is may be too
> simple expression :).

It'd look broadly like this:

/* initialize the interpreter, yada yada */
PyObject *builtins = PyImport_ImportModule("builtins");
PyModule_AddFunctions(builtins, mymodule_methods);

instead of the current module initialization. You import the name
'builtins', stuff some extra stuff into it, and then go on your merry
way. It should be reasonably easy.

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

Re: Strict comparisons in Python 2

[Ian Kelly]

On Tue, Oct 13, 2015 at 9:24 AM, Random832  wrote:
> Ian Kelly  writes:
>> You couldn't do this with a __future__ import because those must be
>> confined to the importing module and are therefore generally limited
>> to syntax changes.
>
> In principle, it could be a syntax change to the < operator (etc) to
> cause it to try to call a different method first, same as division and
> the / operator. That'd be a bit heavyweight to do this late in the
> Python 2 cycle though.

And it also wouldn't change the behavior of list.sort.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Extended functions in embedded code

[Emile van Sebille]

On 10/13/2015 8:29 AM, Ervin Hegedüs wrote:

Hi Chris,

On Wed, Oct 14, 2015 at 02:05:43AM +1100, Chris Angelico wrote:



Sounds to me like the easiest way would be to inject into the
builtins. You should be able to import the builtins module from your C
code, and then stuff some extra attributes into it; they'll be
automatically available to the script, same as the "normal" built-in
names like int, super, and ValueError.


well, sounds good - this solution would be right for me. Could
you show me a good example and/or documentation about this? I've
looked up, but "python extend built-in module" is may be too
simple expression :).


Maybe the site module helps you. See 
https://docs.python.org/3/library/site.html


Emile



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

Re: Some Help getting started

[jogaserbia]

Hi Glenn,

Welcome to the community and thank you for creating this module.  It's great 
you want to get this going in Python (3?).

A couple of things:

1) I looked at the github repo.  You do not have anything to be deployed there. 
 Actually, that repo has nothing to do with python as of yet, aside from the 
init and setup files.  
2) What are you trying to achieve with the pip install -e?  
http://stackoverflow.com/questions/18068077/format-error-when-using-pip-install-e-from-github-value-of-using-egg
http://pip.readthedocs.org/en/stable/reference/pip_install/#editable-installs
I have never used the -e, so someone else might be able to chime in.  Also, 
.egg is in your .gitignore file.  
3) unless you have a particular reason for adding the .idea folder to be 
tracked, I would add it to git ignore.
4) If you want to comply with pep8, 
https://www.python.org/dev/peps/pep-0008/#package-and-module-names 
your module should be called bondlab or bond_lab if really necessary.  

For #1) I would add the folder for the actual module in there as bondlab or 
bond_lab.  I prefer the former (in keeping with numpy, scipy, pandas naming 
conventions, but that is personal preference.)

#2) I assume you are just looking to start using version control for your 
project.  use the git clone  if 
that is the case.  

#3 add the .idea folder to the gitignore

#4) see #1 resolution

I'll send a pull request with these changes if you like them.

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

Re: Some Help getting started

[jogaserbia]

Forgot to mention.  you might want to take a look at numpy and pandas for their 
structures.  

https://github.com/numpy/numpy 
https://github.com/pydata/pandas 

I always find it easier to look at something concrete. 

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

Re: Strong typing implementation for Python

[Sibylle Koczian]

Am 13.10.2015 um 00:10 schrieb Ben Finney:

Sibylle Koczian  writes:


Am 12.10.2015 um 13:39 schrieb Steven D'Aprano:

Auto-complete is a fine and useful tool. But if you are crippled as a
programmer without it, well, then you can hardly claim to understand the
language or framework you are programming in if you cannot use it without
an IDE doing half the work for you.



Well ... you're certainly quite right as far as Python and its
standard library is concerned. But I don't know who would really want
to use .NET without auto-complete and for all I know Java may be just
as awful.


Yes, and that is quite compatible with Steven's assertion. The two
assertions:

* A programmer who feels crippled without auto-complete cannot claim to
   understand the language or framework they're programming in.
   (assertion made by Steven)

* The overwhelming majority of .NET and Java programmers would feel
   crippled without auto-complete. (assertion made by Sibylle)

Not really wanting to do without x isn't the same as feeling crippled 
without it.



can both be true. An obvious resolution is to conclude that the
overwhelming majority of Java and .NET programmers cannot claim to
understand those technologies.

I don't think you can measure understanding by the ability and 
willingness (!) to type those overlong and yet similar names again and 
again in full.



Python, on the other hand, has the huge advantage that programming in
even a bare minimal editor is feasible, and editor features that make
the programmer's life easier are conveniences, not essential to be
competent in Python.

Only one of its huge advantages. As long as no GUI is necessary ... but 
that's another story.


Sibylle


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

request

[Uday Pethakamsetty]

Hi

I am working on python 2.x for long time.

I thought of testing python 3.5 for possible usage.

The problem is that when I installed python 3.5, all the pip installs are 
directing to python 3.5, instead of my native python 2.7.

I heard of a feature called pylauancher; but I didn't find any satisfying 
documentation on it.

Either pylauncer, or something else Solution-could you help reply the possible 
solution to work comfortably on either versions, without interfering, in my 
windows 64 bit machine.


Thanks & regards

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

Re: request

[paul.hermeneutic]

On Oct 13, 2015 1:16 PM, "Uday Pethakamsetty" 
wrote:

> The problem is that when I installed python 3.5, all the pip installs are
directing to python 3.5, instead of my native python 2.7.
>

Probably, this is because the Python 3 directories appears first in the
PATH variable.

Python 3 has venv. I always use venv and never put Python in the PATH
variable.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: request

[Mathew Carrick]

Hi Uday,

Pip should support using the pip{version} command to install
version-specific packages. Try using pip2.7 to install 2.7 packages.

Best,
Mathew Carrick

On Tue, Oct 13, 2015 at 2:45 AM, Uday Pethakamsetty <
uday.pethakamse...@infor.com> wrote:

> Hi
>
>
>
> I am working on python 2.x for long time.
>
>
>
> I thought of testing python 3.5 for possible usage.
>
>
>
> The problem is that when I installed python 3.5, all the pip installs are
> directing to python 3.5, instead of my native python 2.7.
>
>
>
> I heard of a feature called pylauancher; but I didn’t find any satisfying
> documentation on it.
>
>
>
> Either pylauncer, or something else Solution—could you help reply the
> possible solution to work comfortably on either versions, without
> interfering, in my windows 64 bit machine.
>
>
>
>
>
> Thanks & regards
>
>
>
> Udhay Prakash
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: request

[Laura Creighton]

In a message of Tue, 13 Oct 2015 13:28:29 -0600, paul.hermeneu...@gmail.com wri
tes:
>On Oct 13, 2015 1:16 PM, "Uday Pethakamsetty" 
>wrote:
>
>> The problem is that when I installed python 3.5, all the pip installs are
>directing to python 3.5, instead of my native python 2.7.
>>
>
>Probably, this is because the Python 3 directories appears first in the
>PATH variable.
>
>Python 3 has venv. I always use venv and never put Python in the PATH
>variable.
>
>-- 
>https://mail.python.org/mailman/listinfo/python-list

Then you must only be using different Python 3 versions, because venv
won't make you a Python 2.7.  virtualenv will, though.

pip2.7 will get your pip installs to 2.7.

Laura

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

Re: Extended functions in embedded code

[Ervin Hegedüs]

Hi Chris,

what I misses: currently I'm using Python 2.7.

On Wed, Oct 14, 2015 at 02:48:57AM +1100, Chris Angelico wrote:
> On Wed, Oct 14, 2015 at 2:29 AM, Ervin Hegedüs  wrote:
> >>
> >> Sounds to me like the easiest way would be to inject into the
> >> builtins. You should be able to import the builtins module from your C
> >> code, and then stuff some extra attributes into it; they'll be
> >> automatically available to the script, same as the "normal" built-in
> >> names like int, super, and ValueError.
> >
> > well, sounds good - this solution would be right for me. Could
> > you show me a good example and/or documentation about this? I've
> > looked up, but "python extend built-in module" is may be too
> > simple expression :).
> 
> It'd look broadly like this:
> 
> /* initialize the interpreter, yada yada */
> PyObject *builtins = PyImport_ImportModule("builtins");
> PyModule_AddFunctions(builtins, mymodule_methods);

PyModule_AddFunction was introduced in Python 3.5. Most of stable
Linux distribution has Python 3.4
 
> instead of the current module initialization. You import the name
> 'builtins', stuff some extra stuff into it, and then go on your merry
> way. It should be reasonably easy.

Is there any other solution to add functions to builtins?


Thanks,

a.
 

-- 
I � UTF-8
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Extended functions in embedded code

[Ervin Hegedüs]

Hi,

On Tue, Oct 13, 2015 at 08:55:42AM -0700, Emile van Sebille wrote:
> On 10/13/2015 8:29 AM, Ervin Hegedüs wrote:
> >Hi Chris,
> >
> >On Wed, Oct 14, 2015 at 02:05:43AM +1100, Chris Angelico wrote:
> 
> >>Sounds to me like the easiest way would be to inject into the
> >>builtins. You should be able to import the builtins module from your C
> >>code, and then stuff some extra attributes into it; they'll be
> >>automatically available to the script, same as the "normal" built-in
> >>names like int, super, and ValueError.
> >
> >well, sounds good - this solution would be right for me. Could
> >you show me a good example and/or documentation about this? I've
> >looked up, but "python extend built-in module" is may be too
> >simple expression :).
> 
> Maybe the site module helps you. See
> https://docs.python.org/3/library/site.html

no, I think this module is totally different, what I need.


thanks,

a.


-- 
I � UTF-8
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Extended functions in embedded code

[Emile van Sebille]

On 10/13/2015 1:32 PM, Ervin Hegedüs wrote:

Hi,

On Tue, Oct 13, 2015 at 08:55:42AM -0700, Emile van Sebille wrote:

On 10/13/2015 8:29 AM, Ervin Hegedüs wrote:

Hi Chris,

On Wed, Oct 14, 2015 at 02:05:43AM +1100, Chris Angelico wrote:



Sounds to me like the easiest way would be to inject into the
builtins. You should be able to import the builtins module from your C
code, and then stuff some extra attributes into it; they'll be
automatically available to the script, same as the "normal" built-in
names like int, super, and ValueError.


well, sounds good - this solution would be right for me. Could
you show me a good example and/or documentation about this? I've
looked up, but "python extend built-in module" is may be too
simple expression :).


Maybe the site module helps you. See
https://docs.python.org/3/library/site.html


no, I think this module is totally different, what I need.



or perhaps 
http://stackoverflow.com/questions/8608587/finding-the-source-code-for-built-in-python-functions


Emile



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

Re: Extended functions in embedded code

[Laura Creighton]

In a message of Tue, 13 Oct 2015 22:28:54 +0200, Ervin Hegedüs writes:
>Hi Chris,
>
>what I misses: currently I'm using Python 2.7.
>
>On Wed, Oct 14, 2015 at 02:48:57AM +1100, Chris Angelico wrote:
>> On Wed, Oct 14, 2015 at 2:29 AM, Ervin Hegedüs  wrote:
>> >>
>> >> Sounds to me like the easiest way would be to inject into the
>> >> builtins. You should be able to import the builtins module from your C
>> >> code, and then stuff some extra attributes into it; they'll be
>> >> automatically available to the script, same as the "normal" built-in
>> >> names like int, super, and ValueError.
>> >
>> > well, sounds good - this solution would be right for me. Could
>> > you show me a good example and/or documentation about this? I've
>> > looked up, but "python extend built-in module" is may be too
>> > simple expression :).
>> 
>> It'd look broadly like this:
>> 
>> /* initialize the interpreter, yada yada */
>> PyObject *builtins = PyImport_ImportModule("builtins");
>> PyModule_AddFunctions(builtins, mymodule_methods);
>
>PyModule_AddFunction was introduced in Python 3.5. Most of stable
>Linux distribution has Python 3.4
> 
>> instead of the current module initialization. You import the name
>> 'builtins', stuff some extra stuff into it, and then go on your merry
>> way. It should be reasonably easy.
>
>Is there any other solution to add functions to builtins?
>
>
>Thanks,
>
>a.

You can stuff things into the __dict__ of __builtin__ if you like.
It's highly frowned upon.
But see discussion attatched to:
http://code.activestate.com/recipes/577888-see-what-the-builtins-are/

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

Re: Strong typing implementation for Python

[Gregory Ewing]

Ben Finney wrote:


* The overwhelming majority of .NET and Java programmers would feel
  crippled without auto-complete. (assertion made by Sibylle)

An obvious resolution is to conclude that the
overwhelming majority of Java and .NET programmers cannot claim to
understand those technologies.


As a data point, I've been doing some fairly intensive
Java programming recently, and doing it in a very plain
text editor with no auto-completion at all.

While I do make a lot of use of docs during the process,
it's not so much to find out how a name is spelled, but
for higher-level things like which methods a class has,
or even which class I should be using in the first
place, and how to go about using it.

Also, once I've got the information needed for a
particular session paged into my brain, it usually stays
there at least for the rest of the session, so I'm not
having to constantly consult the docs for every little
thing.

So at least for me, it *is* possible to be productive
in Java without special editor support. In Python it's
even easier, due to the general smallness and consistency
of everything.

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

Re: Strong typing implementation for Python

[Gregory Ewing]

Bartc wrote:
I've surprised Basic needs it. The last time I looked, $A was a string, 
%B an integer, and C a number.


A$ and B%, actually.

Although if you didn't like the type suffixes, you
could say DEFINT I-N and pretend you were writing
Fortran code. :-)

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

Re: Strong typing implementation for Python

[Gregory Ewing]

m wrote:

W dniu 13.10.2015 o 03:35, Michael Torrie pisze:


Well in Java code for one.  No wonder they require auto-completion.
Java class-based namespaces must be a nightmare to work with. 


IMHO mainly because their naming convention. They just love typing long
names.


The biggest verbosity problems in Java stem from the
inability to define short aliases for fully-qualified
class names and complicated type expressions.

Ever since generic types were added, omitting such a
feature has been obviously insane, yet somehow nothing
has been done about it.

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

Re: Extended functions in embedded code

[Chris Angelico]

On Wed, Oct 14, 2015 at 7:28 AM, Ervin Hegedüs  wrote:
> Hi Chris,
>
> what I misses: currently I'm using Python 2.7.

Oh, sorry. In that case, you'll be importing "__builtin__" rather than
"builtins", but the same technique works.

> On Wed, Oct 14, 2015 at 02:48:57AM +1100, Chris Angelico wrote:
>> It'd look broadly like this:
>>
>> /* initialize the interpreter, yada yada */
>> PyObject *builtins = PyImport_ImportModule("builtins");
>> PyModule_AddFunctions(builtins, mymodule_methods);
>
> PyModule_AddFunction was introduced in Python 3.5. Most of stable
> Linux distribution has Python 3.4

It's been years since I actually did this, so I cheated and just
flipped through the docs :) But there'll be a way to create a Python
function from a C function, and then you can simply stuff that into
the module's dictionary.

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

Re: Strong typing implementation for Python

[Josef Pktd]

On Tuesday, October 13, 2015 at 2:52:32 PM UTC-4, Sibylle Koczian wrote:
> Am 13.10.2015 um 00:10 schrieb Ben Finney:
> > Sibylle Koczian <> writes:
> >
> >> Am 12.10.2015 um 13:39 schrieb Steven D'Aprano:
> >>> Auto-complete is a fine and useful tool. But if you are crippled as a
> >>> programmer without it, well, then you can hardly claim to understand the
> >>> language or framework you are programming in if you cannot use it without
> >>> an IDE doing half the work for you.
> >>>
> >>
> >> Well ... you're certainly quite right as far as Python and its
> >> standard library is concerned. But I don't know who would really want
> >> to use .NET without auto-complete and for all I know Java may be just
> >> as awful.
> >
> > Yes, and that is quite compatible with Steven's assertion. The two
> > assertions:
> >
> > * A programmer who feels crippled without auto-complete cannot claim to
> >understand the language or framework they're programming in.
> >(assertion made by Steven)
> >
> > * The overwhelming majority of .NET and Java programmers would feel
> >crippled without auto-complete. (assertion made by Sibylle)
> >
> Not really wanting to do without x isn't the same as feeling crippled 
> without it.

To support this

I have been writing numpy/scipy based code in python for many years, and still 
I make a lot more mistakes without autocompletion and having pyflakes or 
similar run in the editor in the background.

I know roughly where everything is in a large class hierarchy with more 
information hidden in attached classes (instances). But it's easy to figure out 
the details with code completion and standard inspection.
It works pretty well maybe 90 % of the time (except in chained expressions).
I also memorize only the main arguments in the signatures, and rely for the 
rest on the pop-up hints.

> 
> > can both be true. An obvious resolution is to conclude that the
> > overwhelming majority of Java and .NET programmers cannot claim to
> > understand those technologies.
> >
> I don't think you can measure understanding by the ability and 
> willingness (!) to type those overlong and yet similar names again and 
> again in full.
> 
> > Python, on the other hand, has the huge advantage that programming in
> > even a bare minimal editor is feasible, and editor features that make
> > the programmer's life easier are conveniences, not essential to be
> > competent in Python.
> >
> Only one of its huge advantages. As long as no GUI is necessary ... but 
> that's another story.

I don't know about GUI programming, but even though it's not part of the 
language there are packages for example for asserting and maintaining types and 
restriction on values like traits and traitlets.

Josef


> 
> Sibylle

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

Re: Strong typing implementation for Python

[Josef Pktd]

On Tuesday, October 13, 2015 at 9:40:56 AM UTC-4, Steven D'Aprano wrote:
> On Tue, 13 Oct 2015 06:55 pm, Todd wrote:
> 
> > On Oct 13, 2015 2:11 AM, "Steven D'Aprano" <...> wrote:
> 
> >> Consider the following piece of code:
> >>
> >> def addone(x):
> >> return x + 1
> >>
> >>
> >> The human programmer reading that can trivially infer that x must be a
> >> number (or at least something which supports numeric addition). So can
> >> the compiler. In a strongly typed language with no numeric promotion, the
> >> compiler can infer that x must be an int. In a language with numeric
> >> promotion, it can infer that x must be an int or float.
> > 
> > Or a decimal, complex number, numpy array, any one of a dozen or so pandas
> > classes, any one of the dozen or so units classes, sympy variable, etc...

A good example is `y = x * 2` followed by long calculations with y.

I have no idea what this does if I don't know the type of x.
(list and tuples get duplicated, arrays as in numpy or pandas multiply 
elementwise, matrix packages use dot (@) product. Two out of three will give us 
the wrong result but don't raise a runtime exception.)

The flip side of the flexibility with dynamic typing is that we spend a lot of 
time and effort in asserting or converting types.

There are cases when being able to quack is not enough, it needs to have the 
right quack. And when we allow for different sounds created by the duck 
look-a-likes, then code can get complicated and avoiding subtle mistakes will 
become very difficult.

Annotations might help the editors, but doesn't enforce the right behavior.
Also, in some cases we don't want to restrict ducktyping in the function or 
method arguments but we need to protect our calculations. Function annotations 
won't help her.

One common pattern then guarantees fixed types within a function:

def calculate_something(x):


x = numpy.asarray(x, numpy.float64)  # convert anything array_like to array

do calculations that only use numpy arrays


return result

In the center we have static types (as far as numpy arrays are static), and we 
don't have to guess on what methods are actually doing, and code inspection 
could infer this.

Outside we still have all the flexibility of duck typing.

I guess it's gradual typing but not through unenforced function annotations.

Josef


> 
> I knew my over-simplification would get me in trouble...
> 
> Firstly, if we're talking about Python specifically, the compiler won't
> actually infer anything (see PEP 484, which "assumes the existence of a
> separate off-line type checker which users can run over their source code
> voluntarily"). It is up to the external type checker (or linter, IDE,
> documentation generator, refactoring tool, etc) to perform any type checks.
> 
> Secondly, what the tool actually infers will depend on the tool. I would
> expect that a basic type checker (say, in a text editor) will infer that x
> is an int or float only. A more powerful checker might infer the Number ABC
> (Abstract Base Class). A specialist checker might even know about numpy,
> pandas, units and sympy, but I wouldn't expect a general-purpose type
> checker to infer them.
> 
> If the programmer cares about such specialist types, then she can easily add
> type hints to supplement the checker's type inference, or the checker
> itself may be configurable. That's a *quality of implementation* detail.
> 
> The beauty of *gradual typing* is that you don't have to care about every
> possible class in the entire universe of Python code, only about the
> classes you actually care about in the parts of your code you choose to
> type check.
> 
> http://wphomes.soic.indiana.edu/jsiek/what-is-gradual-typing/
> 
> Because the Python interpreter itself doesn't care about the compile-time
> type checking, if the checker gets in your way, you can just *not run it*.
> I also expect that good checkers will include directives to skip sections
> of code, so you can include annotations as documentation while still
> silencing over-strict or incorrect compile-time type errors. (Runtime type
> errors will still occur as normal.)
> 
> 
> 
> -- 
> Steven

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

Re: Strict comparisons in Python 2

[Terry Reedy]

On 10/13/2015 9:43 AM, Steven D'Aprano wrote:

In Python 3, comparisons between arbitrary types raise TypeError:

py> None < 2
Traceback (most recent call last):
   File "", line 1, in 
TypeError: unorderable types: NoneType() < int()


In Python 2, that same comparison will arbitrarily return True or False,
according to some implementation-dependent rule.

Is there some way to force the Python 3 rules into Python 2? Something like
a __future__ import?


Not what you want, but ...

1. Only compare instances of classes with rich comparison methods that 
act as in Py 3, subsetting or wrapping builtins as needed.


2. Replace binary operation such as `None < 2` with

a. Conditional expression:
   None < 2 if compatible(a, b, comp) else None
   where compatible returns True for py3, True or TypeError for py2

b. Generic comparison function compare(a, b, comp):
   if compatible(a, b, comp):
  if comp = 'lt': return a < b

c. Specific comparison functon, such as lt(a, b).

I think a 2&3 package should have something like 2c, but I don't know
any particulars.

--
Terry Jan Reedy

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

Re: request

[Zachary Ware]

On Tue, Oct 13, 2015 at 5:45 AM, Uday Pethakamsetty
 wrote:
> Hi
>
> I am working on python 2.x for long time.
>
> I thought of testing python 3.5 for possible usage.
>
> The problem is that when I installed python 3.5, all the pip installs are
> directing to python 3.5, instead of my native python 2.7.
>
> I heard of a feature called pylauancher; but I didn’t find any satisfying
> documentation on it.
>
> Either pylauncer, or something else Solution—could you help reply the
> possible solution to work comfortably on either versions, without
> interfering, in my windows 64 bit machine.

The Python Launcher for Windows is installed by default with Python
3.3+.  It should be on your PATH, and is called 'py.exe'.  It will
launch any Python it can find in the registry, including Python 2.7.
To use it to install something to the global Python 2.7 site-packages,
do `py -2.7 -m pip install `.

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

Re: [mdi...@grulic.org.ar: modifying locals]

[dieter]

Marcos Dione  writes:
> ...
> My problem is modifying the
> locals ...

In Python 2.7, I succeeded with the following code:

>>> def f():
...   x = 1
...   exec('x=2')
...   return x
... 
>>> f()
2


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

Re: Extended functions in embedded code

[Ervin Hegedüs]

On Wed, Oct 14, 2015 at 12:02:36AM +0200, Laura Creighton wrote:
> In a message of Tue, 13 Oct 2015 22:28:54 +0200, Ervin Hegedüs writes:
> >Hi Chris,
> >
> >what I misses: currently I'm using Python 2.7.
> >
> >On Wed, Oct 14, 2015 at 02:48:57AM +1100, Chris Angelico wrote:
[...]

> >
> >PyModule_AddFunction was introduced in Python 3.5. Most of stable
> >Linux distribution has Python 3.4
> > 
> >> instead of the current module initialization. You import the name
> >> 'builtins', stuff some extra stuff into it, and then go on your merry
> >> way. It should be reasonably easy.
> >
> >Is there any other solution to add functions to builtins?
> >
> 
> You can stuff things into the __dict__ of __builtin__ if you like.
> It's highly frowned upon.
> But see discussion attatched to:
> http://code.activestate.com/recipes/577888-see-what-the-builtins-are/

As I understand this, it shows the Python's builtins (or
__builtins__) capabilities.

As Chris wrote, the soultion would be, that I'm loading the
__builtins__ module in C (through API), and add/extend its
__dict__ with my funtions.

The link above doesn't help me in this :).

Thanks,

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