@MRAB, I'm building a notepad++ plugin which can execute the
written code and if one writes help(os) it gets executed via
exec(editor.getText()) and output redirected to the plugin console window.
Sorry to you as well as I have also replied to you directly.
Thank you
--
https://mail.python.org/mai
Just saw, that I replied to you directly instead to python list, sorry.
That did it, changed encoding from function to property and now I'm able to
call help(object)
Thank you.
--
https://mail.python.org/mailman/listinfo/python-list
On 2019-08-31 13:16, Eko palypse wrote:
I've already sent this through mail yesterday but it doesn't appear here, maybe
because of the help word in the content. Please execute in case it appears a
second time.
Hello,
I'm creating a notepad++ plugin which hosts an embedded pyt
Eko palypse wrote:
> I've already sent this through mail yesterday but it doesn't appear here,
> maybe because of the help word in the content. Please execute in case it
> appears a second time.
>
>
> Hello,
> I'm creating a notepad++ plugin which hosts an em
I've already sent this through mail yesterday but it doesn't appear here, maybe
because of the help word in the content. Please execute in case it appears a
second time.
Hello,
I'm creating a notepad++ plugin which hosts an embedded python interpreter by
using cffi to build the
Hello,
I'm creating a notepad++ plugin which hosts an embedded python interpreter
by using cffi to build the dll.
So far so good. One obstacle I've found is that I'm not able to use
exec(help(object)) in order to get the wanted info from the object.
The error I get is:
Traceba
sing the python27 installer generates some
> > dlls "on the fly" that are tied to the windows operating
> system...
> >
> > I dont want to create a windows executable via py2exe or
> > pyinstaller.. What are the best steps to make a python
> in
gt; Why is this behaviour? Im guessing the python27 installer generates some
> dlls "on the fly" that are tied to the windows operating system...
>
> I dont want to create a windows executable via py2exe or
> pyinstaller.. What are the best steps to make a pyth
our? Im guessing the python27 installer generates some
dlls "on the fly" that are tied to the windows operating system...
I dont want to create a windows executable via py2exe or
pyinstaller.. What are the best steps to make a python interpreter
available to all windows
On 2018-08-16 14:33, Chris Angelico wrote:
> On Thu, Aug 16, 2018 at 8:32 PM, Thomas Jollans wrote:
>> On 2018-08-16 01:05, Chris Angelico wrote:
>>> On Thu, Aug 16, 2018 at 8:51 AM, Cameron Simpson wrote:
And as an additional alternative, when I want something weird (extra python
args
On Thu, Aug 16, 2018 at 8:32 PM, Thomas Jollans wrote:
> On 2018-08-16 01:05, Chris Angelico wrote:
>> On Thu, Aug 16, 2018 at 8:51 AM, Cameron Simpson wrote:
>>> And as an additional alternative, when I want something weird (extra python
>>> args or the like) I usually make my script.py into a m
On 2018-08-16 01:05, Chris Angelico wrote:
> On Thu, Aug 16, 2018 at 8:51 AM, Cameron Simpson wrote:
>> And as an additional alternative, when I want something weird (extra python
>> args or the like) I usually make my script.py into a module and invoke it
>> via a shell script, eg:
>>
>> #!/bin/
David Raymond writes:
> So what are you saying is an option vs an argument? Because I see no
> distinction whatsoever.
The command-line conventions do recognise the distinction.
* A command-line argument specifies input to the program.
For example, the destination file for a ‘cp’ command is
Thanks to everyone who contributed to this thread. Great feedback and
suggestions! - Malcolm
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, Aug 16, 2018 at 8:51 AM, Cameron Simpson wrote:
> And as an additional alternative, when I want something weird (extra python
> args or the like) I usually make my script.py into a module and invoke it
> via a shell script, eg:
>
> #!/bin/sh
> exec /particular/python python-opts... -m sc
On 15Aug2018 20:54, eryk sun wrote:
On Wed, Aug 15, 2018 at 9:22 AM, Thomas Jollans wrote:
If you really want to, you can pass a *single* argument in your #! line,
e.g.:
#!/usr/bin/python3 -Wd
This works for options that can be grouped into a single argument.
Multiple -X options aren't supp
On Wed, Aug 15, 2018 at 9:22 AM, Thomas Jollans wrote:
>
> If you really want to, you can pass a *single* argument in your #! line,
> e.g.:
>
> #!/usr/bin/python3 -Wd
This works for options that can be grouped into a single argument.
Multiple -X options aren't supported, nor is combining a -X opt
esday, August 14, 2018 7:47 PM
To: python-list@python.org
Subject: Re: How to pass Python command line options (vs arguments) when
running script directly vs via Python interpreter?
> You might try:
> from getopt import getopt
> or the (apparently newer):
> from optparse import Opti
On 14/08/18 23:45, Malcolm Greene wrote:
> When you run a script via "python3 script.py" you can include command
> line options like -b, -B, -O, -OO, etc between the "python3" interpreter
> reference and the script.py file, eg. "python3 -b -B -O -OO script.py".
> When you create a script that is ex
> You might try:
> from getopt import getopt
> or the (apparently newer):
> from optparse import OptionParser
Thanks Mike. My question was trying to make a distinction between Python
options (flags that precede the script or module name) and arguments (the
script specific values passed on the co
> If you run the script directly, by entering >script.py or clicking a script
> icon or name in File Explorer, it runs python without python options *other
> than those specified in environmental variables*.
Understood. I thought there might have been a way to pass Python option values
via a si
On 2018-08-14 16:45, Malcolm Greene wrote:
> When you run a script via "python3 script.py" you can include command
> line options like -b, -B, -O, -OO, etc between the "python3" interpreter
> reference and the script.py file, eg. "python3 -b -B -O -OO script.py".
> When you create a script that is
On 8/14/2018 5:45 PM, Malcolm Greene wrote:
When you run a script via "python3 script.py" you can include command
line options like -b, -B, -O, -OO, etc between the "python3" interpreter
reference and the script.py file, eg. "python3 -b -B -O -OO script.py".
More generally,
python script.py
When you run a script via "python3 script.py" you can include command
line options like -b, -B, -O, -OO, etc between the "python3" interpreter
reference and the script.py file, eg. "python3 -b -B -O -OO script.py".
When you create a script that is executable directly, eg. script.py with
execution b
On Sat, Aug 4, 2018 at 12:03 AM, Oscar Benjamin
wrote:
> On 2 August 2018 at 20:54, wrote:
>>
>>> As others have mentioned, separate threads for the individual pipes
>>> may help, or if you need to go that far there are specialised
>>> libraries, I believe (pexpect is one, but from what I know i
On 2 August 2018 at 20:54, wrote:
>
>> As others have mentioned, separate threads for the individual pipes
>> may help, or if you need to go that far there are specialised
>> libraries, I believe (pexpect is one, but from what I know it's fairly
>> Unix-specific, so I'm not very familiar with it)
On 8/2/2018 3:52 PM, cseber...@gmail.com wrote:
subprocess is not meant for interaction through the pipes. That is why,
I have been told, IDLE uses a socket for interaction. Multiprocess is
apparently better suited for interaction without resorting to a socket.
So use normal socket on local
sume any particular
interleaving of input and output on the part of the child. If you
control the child process, you can implement a custom protocol to do
the communication, and avoid many of the problems that way.
If you're trying to "wrap" something like the Python interpreter, it&#x
> Another possibility: If the ONLY thing you're doing with stdout/stderr
> is passing them through to the screen, simply don't change them. Let
> them remain bound to the console. You can have a pipe for stdin
> without also having pipes for the others. But that won't work if you
> intend to do a
> subprocess is not meant for interaction through the pipes. That is why,
> I have been told, IDLE uses a socket for interaction. Multiprocess is
> apparently better suited for interaction without resorting to a socket.
So use normal socket on localhost for this? Don't you still need subpro
> As others have mentioned, separate threads for the individual pipes
> may help, or if you need to go that far there are specialised
> libraries, I believe (pexpect is one, but from what I know it's fairly
> Unix-specific, so I'm not very familiar with it).
I'm on Linux so pexpect is a possibil
> -I think the Python interpreter actually sends its output to stderr, so to
> capture it you'd probably want it to go to the same place as stdout, so use
> stderr = subprocess.STDOUT
Yes that captured the error messages! Thanks!
> -You're only reading 1 line out out
On Thu, Aug 2, 2018 at 6:46 PM, Paul Moore wrote:
> On Wed, 1 Aug 2018 at 21:17, wrote:
>>
>> I can run python3 interactively in a subprocess w/ Popen but
>> if I sent it text, that throws an exception, the process freezes
>> instead of just printing the exception like the normal interpreter..
>>
On Wed, 1 Aug 2018 at 21:17, wrote:
>
> I can run python3 interactively in a subprocess w/ Popen but
> if I sent it text, that throws an exception, the process freezes
> instead of just printing the exception like the normal interpreter..
> why? how fix? Here is my code below.
>
> (I suspect when
On 8/1/2018 4:11 PM, cseber...@gmail.com wrote:
I can run python3 interactively in a subprocess w/ Popen but
if I sent it text, that throws an exception, the process freezes
instead of just printing the exception like the normal interpreter..
why? how fix? Here is my code below.
(I suspect when
A couple notes:
-I think the Python interpreter actually sends its output to stderr, so to
capture it you'd probably want it to go to the same place as stdout, so use
stderr = subprocess.STDOUT
-You're only reading 1 line out output for each thing, so if 1 command creates
multipl
On Thu, Aug 2, 2018 at 6:11 AM, wrote:
> I can run python3 interactively in a subprocess w/ Popen but
> if I sent it text, that throws an exception, the process freezes
> instead of just printing the exception like the normal interpreter..
> why? how fix? Here is my code below.
>
> (I suspect wh
I can run python3 interactively in a subprocess w/ Popen but
if I sent it text, that throws an exception, the process freezes
instead of just printing the exception like the normal interpreter..
why? how fix? Here is my code below.
(I suspect when there is an exception, there is NO output to stdi
On Friday, January 13, 2017 at 12:09:52 PM UTC-5, Ian wrote:
> On Fri, Jan 13, 2017 at 3:46 AM, Steve D'Aprano
> wrote:
> >
> > http://aosabook.org/en/500L/a-python-interpreter-written-in-python.html
>
> Neat. But not really surprising IMO that it can fit into
On 13/01/2017 18:47, Ian Kelly wrote:
On Fri, Jan 13, 2017 at 11:07 AM, BartC wrote:
Even when it turns out that the actual code on github is 1000 lines rather
than 500! Maybe it grew a bit since the 500 lines was quoted.
I assume they're excluding blank lines, comments and docstrings. And I
On Fri, Jan 13, 2017 at 11:07 AM, BartC wrote:
> Even when it turns out that the actual code on github is 1000 lines rather
> than 500! Maybe it grew a bit since the 500 lines was quoted.
I assume they're excluding blank lines, comments and docstrings. And I
don't know whether the 500 lines is a
On 13/01/2017 17:08, Ian Kelly wrote:
On Fri, Jan 13, 2017 at 3:46 AM, Steve D'Aprano
wrote:
http://aosabook.org/en/500L/a-python-interpreter-written-in-python.html
Neat. But not really surprising IMO that it can fit into 500 lines,
If there are still 120 or so byte-codes, then t
On Fri, Jan 13, 2017 at 3:46 AM, Steve D'Aprano
wrote:
>
> http://aosabook.org/en/500L/a-python-interpreter-written-in-python.html
Neat. But not really surprising IMO that it can fit into 500 lines,
since it doesn't handle compiling Python into bytecode (which is the
hard p
http://aosabook.org/en/500L/a-python-interpreter-written-in-python.html
--
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
On 11/11/2016 03:24 AM, eryk sun wrote:
On Fri, Nov 11, 2016 at 10:46 AM, Thorsten Kampe wrote:
My goal is to verify that other shells/interpreters on Windows work
the same way as Python when running an application or creating a sub-
process. Cmd does not. What's else there? I have Bash here b
On Fri, Nov 11, 2016 at 11:30 AM, Gisle Vanem via Python-list
wrote:
> Thorsten Kampe wrote:
>
>> My goal is to verify that other shells/interpreters on Windows work
>> the same way as Python when running an application or creating a sub-
>> process. Cmd does not. What's else there? I have Bash he
Thorsten Kampe wrote:
> My goal is to verify that other shells/interpreters on Windows work
> the same way as Python when running an application or creating a sub-
> process. Cmd does not. What's else there? I have Bash here but that's
> a Cygwin executable. And Cygwin Python does not work like
On Fri, Nov 11, 2016 at 10:46 AM, Thorsten Kampe
wrote:
> * eryk sun (Fri, 11 Nov 2016 09:55:23 +)
>>
>> If it works like cmd.exe, then it does its own search using %Path%
>> and %PathExt%. For example:
>>
>> C:\>cmd /c "set "PATH=" & cmd"
>> 'cmd' is not recognized as an internal or e
* eryk sun (Fri, 11 Nov 2016 09:55:23 +)
>
> If it works like cmd.exe, then it does its own search using %Path%
> and %PathExt%. For example:
>
> C:\>cmd /c "set "PATH=" & cmd"
> 'cmd' is not recognized as an internal or external command,
> operable program or batch file.
>
> Bu
On Fri, Nov 11, 2016 at 8:56 AM, Thorsten Kampe
wrote:
> * eryk sun (Fri, 11 Nov 2016 06:23:50 +)
>>
>> That's the application directory, which is the first place
>> CreateProcess looks (via the SearchPath call), as both of my examples
>> shows. In my case python.exe is located in the standard
* eryk sun (Fri, 11 Nov 2016 06:23:50 +)
>
> That's the application directory, which is the first place
> CreateProcess looks (via the SearchPath call), as both of my examples
> shows. In my case python.exe is located in the standard 3.5 system
> installation path, "C:\Program Files\Python35".
On Fri, Nov 11, 2016 at 6:01 AM, Thorsten Kampe
wrote:
> * eryk sun (Thu, 10 Nov 2016 23:04:02 +)
>>
>> On Thu, Nov 10, 2016 at 9:58 PM, Thorsten Kampe
>> wrote:
>> >
>> > I'm trying to run a script with a different Python version by
>> > extending the path variable and executing "python.exe"
ror that you're expecting, but I run debian.
>
> Have you tried using os.unsetenv()?
I think you are kind of misunderstanding my intention. I'm actually
trying the opposite: running python.exe by setting F:\PortableApps
\Python3x as the first element in PATH. No Python interpreter
* eryk sun (Thu, 10 Nov 2016 23:04:02 +)
>
> On Thu, Nov 10, 2016 at 9:58 PM, Thorsten Kampe
> wrote:
> >
> > I'm trying to run a script with a different Python version by
> > extending the path variable and executing "python.exe". It looks like
> > subprocess will always run the current exec
On Thu, Nov 10, 2016 at 9:58 PM, Thorsten Kampe
wrote:
>
> I'm trying to run a script with a different Python version by
> extending the path variable and executing "python.exe". It looks like
> subprocess will always run the current executing Python.
WinAPI CreateProcess checks the application d
On 11/10/2016 05:32 PM, Thorsten Kampe wrote:
Yes. That works. But it's not like subprocess should work.
It certainly is odd. I can at least confirm that when I try to run your
code I get the error that you're expecting, but I run debian.
Have you tried using os.unsetenv()?
https://docs.py
* Thomas Nyberg (Thu, 10 Nov 2016 17:07:35 -0500)
>
> On 11/10/2016 04:58 PM, Thorsten Kampe wrote:
> > Hi,
> >
> > I'm trying to run a script with a different Python version by
> > extending the path variable and executing "python.exe". It looks like
> > subprocess will always run the current exe
On 11/10/2016 04:58 PM, Thorsten Kampe wrote:
Hi,
I'm trying to run a script with a different Python version by
extending the path variable and executing "python.exe". It looks like
subprocess will always run the current executing Python.
> [...]
>
Thorsten
Have you tried using the full pa
s, subprocess
os.environ['PATH'] = ''
print(subprocess.check_output(['python.exe', '-V']))
"""
It outputs the version of the current executing Python interpreter
although it should generate an error because Python is not in the
PATH.
Thorsten
--
https://mail.python.org/mailman/listinfo/python-list
Adding
PySys_SetArgv(argc, argv);
did the trick.
--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
--
https://mail.python.org/mailman/listinfo/python-list
I am trying to build a stub exe on Windows that embeds Python and
launches my Tkinter app. I want a full-blown exe program starter because
the various Python freezing tools (py2exe, pyinstaller) do not work to
my satisfaction with Python 3.5.
I am able to get the executable built but I cannot
On Mon, 28 Mar 2016 07:49 am, BartC wrote:
> On 27/03/2016 21:32, Tim Chase wrote:
>> On 2016-03-27 14:28, Steven D'Aprano wrote:
>
>>> In this case, the two lines "fnc" and "next" simply look up the
>>> function names, but without actually calling them. They're not
>>> quite "no-ops", since they
On Sat, 26 Mar 2016 23:30:30 +, John Pote wrote:
> So I have sympathy with the OP, I would expect the compiler to pick this
> up
Why? The code is valid, the compiler knows how to generate the
appropriate bytecode for it.
The compiler isn't "lint".
Reporting code which is actually invalid is
On Mon, Mar 28, 2016 at 7:49 AM, BartC wrote:
> On 27/03/2016 21:32, Tim Chase wrote:
>>
>> On 2016-03-27 14:28, Steven D'Aprano wrote:
>
>
>>> In this case, the two lines "fnc" and "next" simply look up the
>>> function names, but without actually calling them. They're not
>>> quite "no-ops", sin
On 27/03/2016 21:32, Tim Chase wrote:
On 2016-03-27 14:28, Steven D'Aprano wrote:
In this case, the two lines "fnc" and "next" simply look up the
function names, but without actually calling them. They're not
quite "no-ops", since they can fail and raise NameError if the name
doesn't exist, bu
On 2016-03-27 14:28, Steven D'Aprano wrote:
> > So intrigued by this question I tried the following
> > def fnc( n ):
> > print "fnc called with parameter '%d'" % n
> > return n
> >
> > for i in range(0,5):
> > if i%2 == 0:
> > fnc
> > next
> > print i
> >
>
icrosecond later? Because the interpreter can't easily tell if the
calculations will have any side-effects. It might turn out that something
in the expression ends up setting a global variable, or printing output, or
writing to a file, or who knows what?
Now, you and I can read the line and see that
On 26/03/2016 23:30, John Pote wrote:
So intrigued by this question I tried the following
def fnc( n ):
print "fnc called with parameter '%d'" % n
return n
for i in range(0,5):
if i%2 == 0:
fnc
next
print i
and got the same result as the OP
A couple of
(str(x))
eax@fujitsu:~/temp$ ./t.py
0
1
2
3
4
Is it possible to make python complain in this case? Or maybe solve
such an issue somehow else?
I think what you're looking for here is an acknowledgement that
evaluating the name "next" accomplishes nothing. That's not really
(x))
>
> eax@fujitsu:~/temp$ ./t.py
> 0
> 1
> 2
> 3
> 4
>
> Is it possible to make python complain in this case? Or maybe solve
> such an issue somehow else?
I think what you're looking for here is an acknowledgement that
evaluating the name "next" accompl
On Fri, 25 Mar 2016 11:06 pm, Aleksander Alekseev wrote:
> Is it possible to make python complain in this case? Or maybe solve
> such an issue somehow else?
This is a job for a "linter", such as pychecker, pylint or pyflakes. Google
for more if you are interested.
A linter will check your code f
On 25/03/2016 12:06, Aleksander Alekseev wrote:
Hello
Recently I spend half an hour looking for a bug in code like this:
eax@fujitsu:~/temp$ cat ./t.py
#!/usr/bin/env python3
for x in range(0,5):
if x % 2 == 0:
next
print(str(x))
eax@fujitsu:~/temp$ ./t.py
0
1
2
3
4
Is it
On 25 March 2016 at 13:06, Aleksander Alekseev wrote:
> Hello
>
> Recently I spend half an hour looking for a bug in code like this:
>
> eax@fujitsu:~/temp$ cat ./t.py
> #!/usr/bin/env python3
>
> for x in range(0,5):
> if x % 2 == 0:
> next
> print(str(x))
>
> eax@fujitsu:~/temp$
On Sat, Mar 26, 2016 at 9:59 AM Aleksander Alekseev
wrote:
> Hello
>
> Recently I spend half an hour looking for a bug in code like this:
>
> eax@fujitsu:~/temp$ cat ./t.py
> #!/usr/bin/env python3
>
> for x in range(0,5):
> if x % 2 == 0:
> next
> print(str(x))
>
> eax@fujitsu:~/
Hello
Recently I spend half an hour looking for a bug in code like this:
eax@fujitsu:~/temp$ cat ./t.py
#!/usr/bin/env python3
for x in range(0,5):
if x % 2 == 0:
next
print(str(x))
eax@fujitsu:~/temp$ ./t.py
0
1
2
3
4
Is it possible to make python complain in this case? Or m
Am 13.03.2016 um 20:19 schrieb mrihustle12:
Sent from my Sprint Samsung Galaxy S® 6.
Not with this information, we'd need much more. The OS is necessary
information, but not sufficient.
Have you got Python installed? If yes, which version? Where did you get
it and how did you install it?
Sent from my Sprint Samsung Galaxy S® 6.
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Jan 11, 2016 at 6:55 PM, Rickard Englund
wrote:
> On Friday, January 8, 2016 at 11:28:53 PM UTC+1, Michael Torrie wrote:
>> On 01/08/2016 09:18 AM, Rickard Englund wrote:
>> > First, some system info
>> > * Windows 7 (also tested on 8 and 10)
>> > * Python 3.5.1 64bit (previously also test
On Friday, January 8, 2016 at 11:28:53 PM UTC+1, Michael Torrie wrote:
> On 01/08/2016 09:18 AM, Rickard Englund wrote:
> > First, some system info
> > * Windows 7 (also tested on 8 and 10)
> > * Python 3.5.1 64bit (previously also tested using several 3.x versions)
> > (also tested with 32 bit,
On 01/08/2016 09:18 AM, Rickard Englund wrote:
> First, some system info
> * Windows 7 (also tested on 8 and 10)
> * Python 3.5.1 64bit (previously also tested using several 3.x versions)
> (also tested with 32 bit, but with 3.4.2)
> * Microsoft Visual Studio 2015 (earlier version of python als
crash with
> the following stacktrace:
> http://pastebin.com/QpfGrMY0
>
> We initialize the python interpreter using the following:
> http://pastebin.com/uyx6gdMb
>
> We have tried with and without the Py_NoSiteFlag = 1. When removing that flag
> it works for some modules,
x27;s default libraries, such as os or random. For
example, running the single line code "import os" produces a crash with the
following stacktrace:
http://pastebin.com/QpfGrMY0
We initialize the python interpreter using the following:
http://pastebin.com/uyx6gdMb
We have tried with
On Friday, January 23, 2015 at 10:59:46 PM UTC-5, Cameron Simpson wrote:
> On 18Jan2015 16:20, unknown3...@gmail.com wrote:
> >I am experimenting on a fork of vim-plug for managing vim plugins. I wanted
> >to add parallel update support for python since ruby isn't nearly as common.
> >I've come
On 18Jan2015 16:20, unknown3...@gmail.com wrote:
I am experimenting on a fork of vim-plug for managing vim plugins. I wanted to
add parallel update support for python since ruby isn't nearly as common. I've
come across a weird bug that only seems to happen when I'm inside vim, I'm
wondering i
Hi,
I am experimenting on a fork of vim-plug for managing vim plugins. I wanted to
add parallel update support for python since ruby isn't nearly as common. I've
come across a weird bug that only seems to happen when I'm inside vim, I'm
wondering if someone could tell me why.
This problem can
On 06/24/2014 07:04 AM, Chris Angelico wrote:
Here's what I'd try:
import sys
sys.modules[d1.__class__.__module__].__file__
sys.modules[d2.__class__.__module__].__file__
Do those in both environments and see where things are actually coming
from.
Debugging tips always appreciated.
Thanks,
On 06/24/2014 08:58 AM, Chris Angelico wrote:
Basically, C is for writing high level languages in, and Python and
Pike are for writing applications. Life is good.
+1 QOTW
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, Jun 25, 2014 at 1:40 AM, Fabien wrote:
> Other related annoying stuff when learning is the good old 2.7 VS 3 problem:
>
> mowglie@flappi ~ $ apt-cache search SciPy
> [...]
> python-scipy - scientific tools for Python
> python3-scipy - scientific tools for Python 3
>
> mowglie@flappi ~ $ ap
On 24.06.2014 16:35, Chris Angelico wrote:
Would be nice if there could be some clear indication that this is the
official and current repo.
indeed. Also, the install procedure is a bit dangerous for new python
users like me. NetCDF4 is out since 2008, it would be great if SciPy
could support
On Wed, Jun 25, 2014 at 12:27 AM, Fabien wrote:
> netCDF4 has two repositories online, one on google code and one on github. I
> mistakenly installed the old one, then I noticed the new one and obviously
> some old stuffs remained in the dist-packages directory. I removed them from
> my path and e
Hi Chris,
On 24.06.2014 16:04, Chris Angelico wrote:
Here's what I'd try:
>>>import sys
>>>sys.modules[d1.__class__.__module__].__file__
>>>sys.modules[d2.__class__.__module__].__file__
that was it!
netCDF4 has two repositories online, one on google code and one on
github. I mistakenly ins
Well, it 'appears' to be the same type, but given that the File from one is
different from the other, I think they aren't...
Googling a bit, I found the source:
https://code.google.com/p/netcdf4-python/source/browse/trunk/netcdftime.py?r=1117
and it has a 'datetime' which says: "Phony datetime obj
omething I should check with the NetCDF4 package developers.
>
> While The python interpreter can compare them, my pydev environment can't.
> Is pydev doing something "better" then python3 "alone"?
>
Here's what I'd try:
>>> import sys
>>
Hi Chris,
thanks for the hint. Indeed they are not an instance of the same class:
>>> isinstance(d1, datetime)
Out[6]: False
>>> isinstance(d2, datetime)
Out[7]: True
so this is something I should check with the NetCDF4 package developers.
While The python interpreter ca
On Tue, Jun 24, 2014 at 11:28 PM, Fabien wrote:
> So they are two instances of the same object but something in pyDev doesn't
> want to compare them. Any Hint?
Are they really instances of the same class? One of them comes from
/usr/local/lib/python3.3/dist-packages/netcdftime.py and the other
co
Hi,
this is probably not the best place for this topic but I know this forum
is widely read. I take this opportunity and apology at the same time.
If I run this in my python3 interpreter everything works fine:
mowglie@flappi ~ $ python3
Python 3.3.2+ (default, Feb 28 2014, 00:52:16)
[GCC 4.8.
Marko Rauhamaa writes:
> Jabba Laci :
>
>> I tried this:
>>
>> #!/usr/bin/env python -u
>
> The hash-bang notation is quite rigid; it only accepts a single argument
> ("python") to the command ("/usr/bin/env").
>
> I don't know if there is a simple workaround.
Using the relevant environment vari
On Sun, Feb 16, 2014 at 9:32 AM, Jabba Laci wrote:
> #!/usr/bin/env python -u
>
> But if I want to run it from the command line ($ ./unbuffered.py), I
> get this error:
>
> /usr/bin/env: python -u: No such file or directory
>
> env is looking for "python -u" but such a command doesn't exist.
>
> H
Jabba Laci :
> I tried this:
>
> #!/usr/bin/env python -u
The hash-bang notation is quite rigid; it only accepts a single argument
("python") to the command ("/usr/bin/env").
I don't know if there is a simple workaround.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Hi,
The first line in my scripts looks like this:
#!/usr/bin/env python
I would like to use unbuffered output in a script, which can be done
with the -u option, thus I tried this:
#!/usr/bin/env python -u
But if I want to run it from the command line ($ ./unbuffered.py), I
get this error:
/us
1 - 100 of 486 matches
Mail list logo
