Re: Python launcher (PEP 397) and emacs python-mode.el

[Andreas Röhler]

Am 31.01.2013 10:03, schrieb Thomas Heller:

Has someone managed to patch python-mode.el to use
the PEP 397 python launcher when you hit C-c C-c?

It seems that emacs should parse the shebang line in the edited
python script and pass the corresponding arguments to py.exe.



Yes, that's the way python-mode.el acts by default.

AFAIU that launcher is implemented in Python3.3 and should not need any patch 
at all.
Should it not work, please file a bug-report at

https://bugs.launchpad.net/python-mode

Andreas


Thomas





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

Re: Python launcher (PEP 397) and emacs python-mode.el

[Andreas Röhler]

Am 31.01.2013 17:35, schrieb Thomas Heller:

Am 31.01.2013 12:05, schrieb Andreas Röhler:

Am 31.01.2013 10:03, schrieb Thomas Heller:

Has someone managed to patch python-mode.el to use
the PEP 397 python launcher when you hit C-c C-c?

It seems that emacs should parse the shebang line in the edited
python script and pass the corresponding arguments to py.exe.



Yes, that's the way python-mode.el acts by default.

AFAIU that launcher is implemented in Python3.3 and should not need any
patch at all.
Should it not work, please file a bug-report at

https://bugs.launchpad.net/python-mode


Well, let me make these remarks:

1. I'm on Windows, using gnu-emacs 24.2.1, and python-mode.el 6.1.0.
I do not understand how the shebang line is used by python-mode.el,


it uses py-shebang-regexp to determine
- if a shebang is given
- if, yes, which interpreter to run


depending on what I write into it either 'python.exe' is started when
I hit C-c C-c, or I get 'Spawning child process: invalid argument'.
The latter occurs most often when the shebang string contains 'jython'.


please file a bug-report giving some example script which triggers the bug




2. I would like to use the PEP 397 python launcher to start the python
version that is specified in the shebang line.
The python launcher py.exe parses this line when I run 'py script.py',
and then starts the corresponding python interpreter version.
The launcher parses the shebang line by its own rules (see pep397 for
exact details).  One example is this:


#!/usr/bin/python3.1-32
import sys; print(sys.version)


The python launcher starts 'c:\Python31\python.exe -3.1-32 script.py'.



unfortunatly don't have a windows at my disposal.

At linux it would run exactly the interpreter specified. Might be okay for 
windows as shown.



I would like emacs to do the same; however this would require emacs
to do the same shebang line parsing as the launcher does.



So we do - looks like python-mode.el precedes PEP 397  :)

Expecting the bug elsewhere.


Thomas


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

Re: Python launcher (PEP 397) and emacs python-mode.el

[Andreas Röhler]

Am 01.02.2013 00:59, schrieb Vinay Sajip:

Thomas Heller  ctypes.org> writes:


What I meant to write is this:

when the shebang line in script.py contains this:
#!/usr/bin/python3.1-32
then emacs SHOULD run
py.exe -3.1-32 script.py
and the launcher runs
c:\Python31\python.exe script.py


IMO it would be better for emacs to just run

py.exe script.py

and py.exe can read the shebang and do the right thing. This saves the emacs 
code
from having to duplicate the shebang line processing logic that py.exe uses
(which, as we know, is unusual. So for a cross-platform you can have a shebang
line of #!/usr/bin/python3.2, and on Windows it will still call the appropriate
Python 3.2 even if it's not in /usr/bin, as there's no /usr/bin :-))

Regards,

Vinay Sajip





https://bugs.launchpad.net/python-mode/+bug/1112207
--
http://mail.python.org/mailman/listinfo/python-list

Re: Call for Assistance

[Andreas Röhler]

On 12.08.2016 06:48, Lawrence D’Oliveiro wrote:

On Wednesday, August 10, 2016 at 3:42:39 AM UTC+12, Reto Brunner wrote:

What on earth isn't "free" enough about

You are free to:
Share — copy and redistribute the material in any medium or format

No you are not. A court has ruled 

 quite clearly that “non-commercial” means PERSONAL USE ONLY, no redistribution or 
republication.


The court ruled at the special case. The institution in question is paid 
by all germans due to a kind of fea imposed - "Rundfunkbeitrag". 
Everyone owning or renting an object in Germany has to pay to them - 
without regard if they uses that media or not. If you have to pay to 
someone, you would not consider that relation non-commercial.

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

Re: Distinction between “class” and “type”

[Andreas Röhler]

I suspect that one could produce a class that is not a type,


Say: has not a complete type definition. Think of type for example with 
the distinction of strings and numbers.


Types start from low level units. A class definition must know about 
strings and numbers, it inherits this knowledge from the syntax of 
language. Even an empty class must be constructed.


Types may be composed resp derived from other types. Any class finely 
will constitute a type composed by its body.


In case an definition may used for example equally for addition or 
string-concatenation, ambiguity constitutes a composed resp. derived 
type by themselves.


In general terms: the type tells the structure of arguments it receives 
alongside with the way, it deals with them.




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

Re: Operator Precedence/Boolean Logic

[Andreas Röhler]

On 23.06.2016 06:47, Lawrence D’Oliveiro wrote:

On Thursday, June 23, 2016 at 3:12:52 PM UTC+12, Larry Hudson wrote:

On 06/22/2016 12:42 AM, Lawrence D’Oliveiro wrote:

* boolean operators don’t have to operate on boolean values. The
   language spec
   
   says:

 “...the following values are interpreted as false: False, None, numeric
 zero of all types, and empty strings and containers (including strings,
 tuples, lists, dictionaries, sets and frozensets). All other values are
 interpreted as true.”

I feel that’s a needlessly complicated rule. It would have been simpler if
boolean operators (and conditional expressions like in if-statements and
while-statements) only allowed values of boolean types. But that’s one of
the few warts in the design of Python...

Wart??  I *strongly* disagree.  I find it one of the strengths of Python,
it enhances Python's expressiveness.

Tightening it up would rule out a whole class of common errors, from misunderstanding (or 
forgetting) the rule about what exactly gets interpreted as true and what as false 
 
.


Indeed, why should the result of 4 - 4 have a different truth-value than 
4 - 3 ?
This implementation seems to be a legacy from languages without boolean 
types.

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

Re: Operator Precedence/Boolean Logic

[Andreas Röhler]

On 23.06.2016 09:05, Steven D'Aprano wrote:

On Thursday 23 June 2016 16:34, Andreas Röhler wrote:


Indeed, why should the result of 4 - 4 have a different truth-value than
4 - 3 ?

Because 4-4 is zero, which is "nothing",


Hmm,  water freezes at zero degree celsius, because there is no temperature?


  while 4-3 is one, which is
"something".

You might as well ask why False and True have different truth values.
Ironically, in a manner of speaking you *did* ask that, since 4-3 == True and
4-4 == False.




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

Re: Operator Precedence/Boolean Logic

[Andreas Röhler]

On 23.06.2016 10:17, Antoon Pardon wrote:

Op 23-06-16 om 09:05 schreef Steven D'Aprano:

On Thursday 23 June 2016 16:34, Andreas Röhler wrote:


Indeed, why should the result of 4 - 4 have a different truth-value than
4 - 3 ?

Because 4-4 is zero, which is "nothing", while 4-3 is one, which is
"something".

No zero is not nothing. If zere is nothing and an empty list is nothing,
I would expect zero to be an empty list or that they could be used 
interchangebly.




There is a fundamental diff between zero and emptiness.

Zero is just a relation in the realm of integers. It tells being in the 
midst between positiv and negativ infinity.
Number one tells being one unit towards positiv infinity in relation to 
negativ infinity. And so on.


Whilst emptiness tells about non-existence.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Operator Precedence/Boolean Logic

[Andreas Röhler]

On 23.06.2016 11:17, Steven D'Aprano wrote:

[ ... ]
We can derive arithmetic from set theory.


IMO not, resp. not really. But that would make a another item, pretty 
off-topic from Python.


Should you know a place where to continue, would like to follow up.

Thanks BTW.


  Zero is very special: it is defined
as the empty set:

0: {}

The successor of zero (namely, one) is the set of all empty sets:

1: {{}}

Two is the set of zero and one:

2 = {{}, {{}}}

and so forth.





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

Re: Operator Precedence/Boolean Logic

[Andreas Röhler]

On 23.06.2016 11:46, Marko Rauhamaa wrote:


Ridiculous? It was this line of thinking that led Paul Dirac to predict
the existence of antimatter.


Marko


Yeah. Maybe we could construct examples already using antagonistic 
charges of electrons?

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

Re: Operator Precedence/Boolean Logic

[Andreas Röhler]

On 23.06.2016 14:08, Antoon Pardon wrote:

Op 23-06-16 om 13:45 schreef Chris Angelico:

On Thu, Jun 23, 2016 at 7:23 PM, Antoon Pardon
 wrote:

I don't care. In modern mathematics, zero is usaly defined as the
empty set. The empty set contains nothing, but it isn't nothing
itself. Otherwise the empty set would be the same as the set
containing the empty set, since they both would contain the same,
being nothing.

Zero is *the cardinality of* the empty set. The set containing the
empty set has a cardinality of 1.

In modern set theory where the integers are defined as specific kind
of sets, zero *is* the empty set.



Modes are like waves. If one wave arrives being "modern", lets watch out 
for the next.


There not just one set-theory, math is neither revealed nor received on 
some mount - even if the notion of truth has some theological 
connotations ;)

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

Re: Can math.atan2 return INF?

[Andreas Röhler]

On 30.06.2016 03:33, Lawrence D’Oliveiro wrote:


So you see, like it or not, we are drawn to the conclusion that there *was* 
indeed something before our particular Big Bang.


That's linear like the Big Bang theorie. What about assuming something 
beyond our notion of time and space, unknown still?

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

Re: Can math.atan2 return INF?

[Andreas Röhler]

On 30.06.2016 10:24, Steven D'Aprano wrote:

On Thursday 30 June 2016 12:13, Rustom Mody wrote:

[ ... ]
Besides, the whole point of science is to develop objective, rational reasons
to believe things.


Science is not about believing, but about models.
Believing is important to make the career of a scientist maybe, it's for 
people outside.

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

Re: Can math.atan2 return INF?

[Andreas Röhler]

On 30.06.2016 10:24, Steven D'Aprano wrote:

On Thursday 30 June 2016 12:13, Rustom Mody wrote:


The irrational and emotional psychological forces that inspire mathematicians
can make interesting reading, but they have no relevance in deciding who is
write or wrong.


Hmm, so math is not inspired by solving real world problems, for example 
in physics or big-data?




  No numbers are real.


Numbers express relations, which are represented as symbols. So far they 
are real, as math exists, the human mind exists.


We don't have any natural numbers, assume Kronecker made a joke. 
"Natural numbers" is the most misleading term in the field maybe.


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

Re: Can math.atan2 return INF?

[Andreas Röhler]

On 30.06.2016 11:42, Lawrence D’Oliveiro wrote:

On Thursday, June 30, 2016 at 9:31:29 PM UTC+12, Andreas Röhler wrote:


Science is not about believing, but about models.

The nice thing about science is, it works even if you don’t believe in it.



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

Re: Emacs python-mode.el bug #1207470

[Andreas Röhler]

Am 14.02.2014 17:38, schrieb Frank Stutzman:

According to https://bugs.launchpad.net/python-mode/+bug/1207470 this bug
was fixed in version 6.1.2 of python-mode.el.  I am trying to run 6.1.3 and
am running into it.  I back dated to 6.1.2 and still see it there.  I am
running GNU Emacs 23.3.1.

Its possible that something I'm doing it causing it, but I have no idea
what.  I can start emacs with no init file, load python mode, hit enter
and I get the error.

Has anyone else experienced this?  I am sure that Andreas Roehler (the
maintainer of python-mode.el) fixed it, but am thinking that it somehow
didn't make it into the released code.

Frank



Re-opened the ticket mentioned. Please subscribe there, so you may get the 
bug-mail.

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

Re: looking up function's doc in emacs

[Andreas Röhler]

Xah Lee wrote:

> in programing elisp in emacs, i can press “Ctrl+h f” to lookup the doc
> for the function under cursor.
> 
> is there such facility when coding in perl, python, php?
> 
> (i'm interested in particular python. In perl, i can work around with
> “perldoc -f functionName”, and in php it's php.net/functionName. Both
> of which i have a elisp command with a shortcut that let me jump to
> the doc)
> 
> Thanks.
> 
>   Xah
> ∑ http://xahlee.org/
> 
> ☄
python help(FUNCTIONNAME)



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

Re: python setup ?

[Andreas Röhler]

Xavier Maillard wrote:
> Hi
>
>Xavier Maillard  writes:
>
>> I am starting to do some work with python. I am looking for
>> options/setups to introduce into my .emacs file to have the best
>> experience possible with this scripting language.
>>
>> Where should I start ?
>
>I personnaly use python-mode.el that is much better than python.el (that
>come with emacs).
>
> In what is it better ?
>
>I use also ipython as python shell that integrate fine in emacs.
>
> Phew, how many new dependances should I install in order to have
> something simple to use ? :) I thought python was something for
> beginners, it is not. I find it easier to play lisp...
>
>   Xavier
>   
Hi Xavier,

as its well known, you are not a beginner with Emacs,
please permit to take your comment as occasion:

Your question and experience with Emacs and Python
reflects IMHO some general strength and likewise
present limitation.

The strength is, clearly: with that many files out
there, that many people who wrote already something for
python, with some Emacs Lisp knowledge you'll be able
to install a reasonable environment.

OTOH: how many people did that already, spent hours to
collect and adapt utilities from the net? And
afterwards? If we take together all this time from
users configuring an python-environment, we could
probably get more useful results from it. So there is a
lose of time.

Can we do better? ... :)

One thing, thats to realize IMO: times are gone where
one person with some knowledge of a language may write
a mode and thats it. Even maintaining it alone seems to
surpass any personal capacity. If we want to keep path,
we have to establish developer-groups caring for a
language. That happened already with C-modes AFAIS. We
need that for any major language.

Concerning python, we have enough man-power to
perform excellent things. To the extent, user have to do
`M-x python,' and an environment with all up-to-date
debugging facilities gets installed.

No question its great whats done at

http://www.emacswiki.org/emacs/PythonMode

Emacswiki was helpful many times for me.

However, for pure development issues, designed
platforms like Launchpad seem more suitable for the
purpose for me. Beside excellent bazaar behind, lets mention
its email- and bugreport integration.

As it happens we have with Barry Warsaw not just an
experienced Emacs Lisper, but a python core developer
with its python-mode account: we should try our chance
to proceed with his gentle help occasionally.

AFAIS we need tailored accounts, where we maintain
flavours of possible environments, learning and lifting
from each other, enabling distributions to select and
pull for delivering.

So far

Andreas

--
http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/
https://code.launchpad.net/s-x-emacs-werkstatt/



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