Re: best way to ensure './' is at beginning of sys.path?
Steve D'Aprano writes: > On Sat, 4 Feb 2017 10:13 am, Ben Finney wrote: > > See https://www.python.org/dev/peps/pep-0328/>, in particular > > https://www.python.org/dev/peps/pep-0328/#guido-s-decision>. > > I think you are conflating the package directory and . the current > working directory. I was careful not to say “current working directory”, for that reason. I didn't want to open the more complex topic of Python packages, so I let “current directory” stand in for “directory where the current module is located”. I'm glad that distinction did get mentioned, though. -- \ “Capitalism has destroyed our belief in any effective power but | `\ that of self interest backed by force.” —George Bernard Shaw | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: best way to ensure './' is at beginning of sys.path?
On 04Feb2017 13:59, Steve D'Aprano wrote:
On Sat, 4 Feb 2017 01:13 pm, Cameron Simpson wrote:
1. In your .bashrc file, or equivalent, set the environment
variable PYTHONPATH:
export PYTHONPATH='./;$PYTHONPATH'
You want double quotes (allowing parameter substitution) instead of single
quotes here. Or, of course, no quotes at all. And the separator is ":",
not ";".
Thanks for the correction.
Personally, I'm against hacking the $PYTHONPATH this way at all.
Oh? Why's that? This is the whole purpose of PYTHONPATH.
I'm only against doing it "this way", for values of "this way" including
"putting a ., which is totally dependent on my working directory, in my
$PYTHONPATH". I'm sorry I wasn't clear.
Far better to invoke the Python script via a shell script that includes
the absolute path of the current directory (or the module directory) in
the $PYTHONPATH.
For some definition of "better" -- that means you have double the cognitive
load. For every script.py you want, you need to create both script.py (what
you actually want) and script.sh (a wrapper that sets the environment).
Sure, but (I hope) Neal's need is a little special purpose.
Besides, when i do this with "installed" code, generally all the python is in a
module in my normal $PYTHONPATH and the shell script, if it exists (eg to hack
the $PYTHONPATH) looks a bit like this:
#!/bin/sh
set -ue
PYTHONPATH=/path/to/extra/libs:$PYTHONPATH
export PYTHONPATH
exec python -m my.module ${1+"$@"}
So you don't really install 2 scripts. You install a python module in your
normal place, and the invoker is a shell script which might prehack the
environment.
My "dev" script is little different (though it mucks with $PATH and $PERL5LIB
etc as well as $PYTHONPATH), but its whole purpose is to reduce my cognitive
load, which just becomes "I want this directory as the basis for my dev env for
this one command".
Cheers,
Cameron Simpson
--
https://mail.python.org/mailman/listinfo/python-list
Re: best way to ensure './' is at beginning of sys.path?
On Sat, 4 Feb 2017 10:13 am, Ben Finney wrote: > So, for the past ten years and more, Python supports import of modules > from the current directory with an explicit *relative* path:: > > # Absolute imports, searching ‘sys.path’. > import datetime > from collections import namedtuple > > # Relative imports, starting from this module's directory. > from . import foo > from .bar import baz > > See https://www.python.org/dev/peps/pep-0328/>, in particular > https://www.python.org/dev/peps/pep-0328/#guido-s-decision>. I think you are conflating the package directory and . the current working directory. Relative imports do not, as far as I can see, have anything to do with the current working directory. I created these files in a directory under my home directory: [steve@ando ~]$ ls test eggs.py spam.py [steve@ando ~]$ cat test/eggs.py pass [steve@ando ~]$ cat test/spam.py from . import eggs print(eggs.__file__) I cd'ed into the test folder, and tried running spam.py: [steve@ando ~]$ cd test [steve@ando test]$ python3.5 spam.py Traceback (most recent call last): File "spam.py", line 1, in from . import eggs SystemError: Parent module '' not loaded, cannot perform relative import So relative imports using . dot have nothing to do with importing from the current directory. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: best way to ensure './' is at beginning of sys.path?
On Sat, 4 Feb 2017 01:13 pm, Cameron Simpson wrote: >>1. In your .bashrc file, or equivalent, set the environment >> variable PYTHONPATH: >>export PYTHONPATH='./;$PYTHONPATH' > > You want double quotes (allowing parameter substitution) instead of single > quotes here. Or, of course, no quotes at all. And the separator is ":", > not ";". Thanks for the correction. > Personally, I'm against hacking the $PYTHONPATH this way at all. Oh? Why's that? This is the whole purpose of PYTHONPATH. > Far better to invoke the Python script via a shell script that includes > the absolute path of the current directory (or the module directory) in > the $PYTHONPATH. For some definition of "better" -- that means you have double the cognitive load. For every script.py you want, you need to create both script.py (what you actually want) and script.sh (a wrapper that sets the environment). -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: best way to ensure './' is at beginning of sys.path?
CCed to Neal: could you confirm or refute my suppositions below, or further clarify? Thanks. On 04Feb2017 12:46, Steve D'Aprano wrote: On Sat, 4 Feb 2017 10:13 am, Ben Finney wrote: Neal Becker writes: I want to make sure any modules I build in the current directory overide any others. To do this, I'd like sys.path to always have './' at the beginning. The ‘sys.path’ list is used only for *absolute* imports. Modules in the current directory should not be imported with an absolute path[0]. So, the current directory should not be in ‘sys.path’. [...] [0]: Why not? See the rationale for forcing absolute import by default https://www.python.org/dev/peps/pep-0328/#rationale-for-absolute-imports>, “[I]t is not clear whether ‘import foo’ refers to a top-level module or to another module inside the package.[…] It's a particularly difficult problem inside packages because [without explicit relative import syntax] there's no way to specify which module is meant.” I'm not sure that this reasoning applies to Neal's situation. He doesn't seem to be talking about a single package, as such, more like he has a bunch of unrelated libraries in a single directory. My *guess* is that he probably has something like a ~/python or ~/scripts directory, and he likes to cd into that directory before running one of the scripts. I don't know what problem Neal thinks he is solving by always inserting ./ at the front of sys.path. But the rationale above doesn't seem relevant to the *pure technical question* of inserting ./ at the start of sys.path. I think it is relevant. Why? _Because_ we don't have Neal's wider context, which he hasn't provided. Purely technical advice is all very well, and definitiely a necessary component to answers. However, I can't count the number of times I've encountered people requesting a specific technical solution to a problem defined only in terms of the technical task. And when that particular solution is something that is _usually_ a bad idea, one should always accompany the techincal advice with a bit of discussion of related alternatives and the up and downsides. Particularly, why the requested technical solution is often not thought to be a good thing. And ideally with a request for the wider context that _causes_ the OP to request a particular solution. Now, we do actually have a bit of Neal's wider context: I want to make sure any modules I build in the current directory overide any others. His requested _particular_ technical solution is this: To do this, I'd like sys.path to always have './' at the beginning. I think that's probably a poor technical solution for reasons I've alluded to in another post. Ben has provided greater context around that can be done with imports so that Neal can perhaps choose another method with the same outcome in terms of his wider objective. From my own perspective, I often want something that feels like what I think Neal may want: when I'm debugging my own modules I want the "lib/python" subdirectory of my code repository at the start of my Python path in order that imports find my developement modules ahead of their installed/published copies. Now, I have _many_ development directories because I tend to make one for each branch in progress, and just cd to the particular dev tree I'm working on. In this circumstance I've got a personal script called "dev" which prepends the _absolute_ paths of the various lib subdirs to the relevant paths, so it sticks $PWD/lib/python to the front of $PYTHONPATH. And then it executes whatever command I supply: dev python -m cs.venti.store_tests for example. I suspect Neal could do with something like that instead. Neal, could you confirm or refute or clarify how this all fits your situation? Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: best way to ensure './' is at beginning of sys.path?
On 04Feb2017 12:16, Steve D'Aprano wrote: On Sat, 4 Feb 2017 03:06 am, Neal Becker wrote: I want to make sure any modules I build in the current directory overide any others. To do this, I'd like sys.path to always have './' at the beginning. What's the best way to ensure this is always true whenever I run python3? For some definition of "always"... I don't know about "best", but you can do this: 1. In your .bashrc file, or equivalent, set the environment variable PYTHONPATH: export PYTHONPATH='./;$PYTHONPATH' You want double quotes (allowing parameter substitution) instead of single quotes here. Or, of course, no quotes at all. And the separator is ":", not ";". Personally, I'm against hacking the $PYTHONPATH this way at all. Far better to invoke the Python script via a shell script that includes the absolute path of the current directory (or the module directory) in the $PYTHONPATH. Cheers, Cameron Simpson That article and its poster have been canceled. - David B. O'Donnell, Sysadmin, America OnLine -- https://mail.python.org/mailman/listinfo/python-list
Re: best way to ensure './' is at beginning of sys.path?
On Sat, 4 Feb 2017 10:13 am, Ben Finney wrote: > Neal Becker writes: > >> I want to make sure any modules I build in the current directory >> overide any others. To do this, I'd like sys.path to always have './' >> at the beginning. > > The ‘sys.path’ list is used only for *absolute* imports. Modules in the > current directory should not be imported with an absolute path[0]. So, the > current directory should not be in ‘sys.path’. [...] > [0]: Why not? See the rationale for forcing absolute import by default > https://www.python.org/dev/peps/pep-0328/#rationale-for-absolute-imports>, > “[I]t is not clear whether ‘import foo’ refers to a top-level > module or to another module inside the package.[…] It's a > particularly difficult problem inside packages because [without > explicit relative import syntax] there's no way to specify which > module is meant.” I'm not sure that this reasoning applies to Neal's situation. He doesn't seem to be talking about a single package, as such, more like he has a bunch of unrelated libraries in a single directory. My *guess* is that he probably has something like a ~/python or ~/scripts directory, and he likes to cd into that directory before running one of the scripts. I don't know what problem Neal thinks he is solving by always inserting ./ at the front of sys.path. But the rationale above doesn't seem relevant to the *pure technical question* of inserting ./ at the start of sys.path. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: best way to ensure './' is at beginning of sys.path?
On 03Feb2017 17:21, Wildman wrote: On Sat, 04 Feb 2017 09:25:42 +1100, Cameron Simpson wrote: Also, what you describe with rc.local wouldn't work anyway, even if it had ben what was asked. Of course, you are correct. I don't know where my head was. I think my tongue got in front of my eye teeth and I could not see what I was saying. :-) If anyone is interested the correct way is to add this to /etc/profile (at the bottom): PATH=$PATH:./ export PATH Indeed. But this should usually be accompanied by the advice that this isn't a good idea. Having one's commands at the mercy of whatever directory one is standing in is a recipe for being subverted. While the risk is lessened by having "." at the end of the search path, that just means the attacker (== other user of this system) has to name their trojan horse commands after typing errors, such as the ever popular "gerp" search programme. Even with Python I'd feel it is better to not have "." in the sys.path; I'd be happier with a full path to a preferred source of modules. (Yes, I know Python likes to search the current directory for modules, notmy favourite feature.) Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: best way to ensure './' is at beginning of sys.path?
On Sat, 4 Feb 2017 03:06 am, Neal Becker wrote: > I want to make sure any modules I build in the current directory overide > any > others. To do this, I'd like sys.path to always have './' at the > beginning. > > What's the best way to ensure this is always true whenever I run python3? For some definition of "always"... I don't know about "best", but you can do this: 1. In your .bashrc file, or equivalent, set the environment variable PYTHONPATH: export PYTHONPATH='./;$PYTHONPATH' * * * If you need this to be site-wide, rather than per person, another possibility, untested, would be to get your site administrator to create a sitecustomize.py file. Suppose your Python is installed in /usr/local/lib/python3.5/ Get your site admin to create the following file: /usr/local/lib/python3.5/site-packages/sitecustomize.py containing the following code: import sys if './' not in sys.path: sys.path.insert(0, './') * * * * Alternatively, a per-user solution is to create your own usercustomize.py file, containing the same code as above. By default, the per-user site packages directory will be: # Unix: ~/.local/lib/pythonX.Y/site-packages # Mac: ~/Library/Python/X.Y/lib/python/site-packages # Windows: %APPDATA%\Python\PythonXY\site-packages where X Y are the major and minor version numbers, e.g. 3 5. See the documentation for the site module for more detail: https://docs.python.org/3/library/site.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
Re: best way to ensure './' is at beginning of sys.path?
On 04Feb2017 10:13, Ben Finney wrote: Neal Becker writes: I want to make sure any modules I build in the current directory overide any others. To do this, I'd like sys.path to always have './' at the beginning. The ‘sys.path’ list is used only for *absolute* imports. Modules in the current directory should not be imported with an absolute path[0]. So, the current directory should not be in ‘sys.path’. So, for the past ten years and more, Python supports import of modules from the current directory with an explicit *relative* path:: # Absolute imports, searching ‘sys.path’. import datetime from collections import namedtuple # Relative imports, starting from this module's directory. from . import foo from .bar import baz See https://www.python.org/dev/peps/pep-0328/>, in particular https://www.python.org/dev/peps/pep-0328/#guido-s-decision>. I wrote: Yes, I know Python likes to search the current directory for modules, notmy favourite feature. I stand corrected. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: best way to ensure './' is at beginning of sys.path?
On Sat, 04 Feb 2017 09:25:42 +1100, Cameron Simpson wrote: > On 03Feb2017 14:55, Wildman wrote: >>On Fri, 03 Feb 2017 13:19:30 -0700, Michael Torrie wrote: >> >>> On 02/03/2017 12:07 PM, Wildman via Python-list wrote: Sorry, I forgot something important. If you use /etc/rc.local, the execute bit must be set. >>> >>> I don't think this is what Neal Becker was asking about. He's talking >>> about the Python module search path (sys.path) not the operating system >>> PATH variable. Correct me if I'm wrong. >> >>After re-reading the post I see you are correct. >>I will endeavor to read a little closer and a >>little slower in the future. > > Also, what you describe with rc.local wouldn't work anyway, even if it had > ben > what was asked. > > Cheers, > Cameron Simpson Of course, you are correct. I don't know where my head was. I think my tongue got in front of my eye teeth and I could not see what I was saying. :-) If anyone is interested the correct way is to add this to /etc/profile (at the bottom): PATH=$PATH:./ export PATH -- GNU/Linux user #557453 The cow died so I don't need your bull! -- https://mail.python.org/mailman/listinfo/python-list
Re: best way to ensure './' is at beginning of sys.path?
Neal Becker writes: > I want to make sure any modules I build in the current directory > overide any others. To do this, I'd like sys.path to always have './' > at the beginning. The ‘sys.path’ list is used only for *absolute* imports. Modules in the current directory should not be imported with an absolute path[0]. So, the current directory should not be in ‘sys.path’. So, for the past ten years and more, Python supports import of modules from the current directory with an explicit *relative* path:: # Absolute imports, searching ‘sys.path’. import datetime from collections import namedtuple # Relative imports, starting from this module's directory. from . import foo from .bar import baz See https://www.python.org/dev/peps/pep-0328/>, in particular https://www.python.org/dev/peps/pep-0328/#guido-s-decision>. [0]: Why not? See the rationale for forcing absolute import by default https://www.python.org/dev/peps/pep-0328/#rationale-for-absolute-imports>, “[I]t is not clear whether ‘import foo’ refers to a top-level module or to another module inside the package.[…] It's a particularly difficult problem inside packages because [without explicit relative import syntax] there's no way to specify which module is meant.” -- \ “True greatness is measured by how much freedom you give to | `\ others, not by how much you can coerce others to do what you | _o__) want.” —Larry Wall | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
ANN: Wing Python IDE version 6.0.2 released
Hi, We've just released Wing version 6.0.2 which expands and improves support for remote development, adds a drop down of found Python installations, introduces symbol name style refactoring operations, improves multi-selection with the mouse, fixes debugging Jupyter notebooks, and makes many other minor improvements. For details, see the change log at http://wingware.com/pub/wingide/6.0.2/CHANGELOG.txt Wing 6 is the latest major release in Wingware's family of Python IDEs, including Wing Pro, Wing Personal, and Wing 101. Wing 6 adds many new features, introduces a new annual license option, and makes some changes to the product line. New Features * Improved Multiple Selections: Quickly add selections and edit them all at once * Easy Remote Development: Work seamlessly on remote Linux, OS X, and Raspberry Pi systems * Debugging in the Python Shell: Reach breakpoints and exceptions in (and from) the Python Shell * Recursive Debugging: Debug code invoked in the context of stack frames that are already being debugged * PEP 484 and PEP 526 Type Hinting: Inform Wing's static analysis engine of types it cannot infer * Support for Python 3.6 and Stackless 3.4: Use async and other new language features * Optimized debugger: Run faster, particularly in multi-process and multi-threaded code * Support for OS X full screen mode: Zoom to a virtual screen, with auto-hiding menu bar * Added a new One Dark color palette: Enjoy the best dark display style yet * Updated French and German localizations: Thanks to Jean Sanchez, Laurent Fasnacht, and Christoph Heitkamp For a much more detailed overview of new features see the release notice at http://wingware.com/news/2017-02-02 Annual Use License Option Wing 6 adds the option of purchasing a lower-cost expiring annual license for Wing Pro. An annual license includes access to all available Wing Pro versions while it is valid, and then ceases to function if it is now renewed. Pricing for annual licenses is US$ 179/user for Commercial Use and US$ 69/user for Non-Commercial Use. Perpetual licenses for Wing Pro will continue to be available at the same pricing. The cost of extending Support+Upgrades subscriptions on Non-Commercial Use perpetual licenses for Wing Pro has also been dropped from US$ 89 to US$ 39 per user. For details, see https://wingware.com/store/purchase Wing Personal is Free Wing Personal is now free and no longer requires a license to run. It now also includes the Source Browser, PyLint, and OS Commands tools, and supports the scripting API and Perspectives. However, Wing Personal does not include Wing Pro's advanced editing, debugging, testing and code management features, such as remote host access, refactoring, find uses, version control, unit testing, interactive debug probe, multi-process and child process debugging, move program counter, conditional breakpoints, debug watch, framework-specific support (for matplotlib, Django, and others), find symbol in project, and other features. Links Release notice: http://wingware.com/news/2017-02-02 Free trial: http://wingware.com/wingide/trial Downloads: http://wingware.com/downloads Feature list: http://wingware.com/wingide/features Buy: http://wingware.com/store/purchase Upgrade: https://wingware.com/store/upgrade Questions? Don't hesitate to email us at supp...@wingware.com. Thanks, -- Stephan Deibel Wingware | Python IDE The Intelligent Development Environment for Python Programmers wingware.com -- https://mail.python.org/mailman/listinfo/python-list
Re: best way to ensure './' is at beginning of sys.path?
On 03Feb2017 14:55, Wildman wrote: On Fri, 03 Feb 2017 13:19:30 -0700, Michael Torrie wrote: On 02/03/2017 12:07 PM, Wildman via Python-list wrote: Sorry, I forgot something important. If you use /etc/rc.local, the execute bit must be set. I don't think this is what Neal Becker was asking about. He's talking about the Python module search path (sys.path) not the operating system PATH variable. Correct me if I'm wrong. After re-reading the post I see you are correct. I will endeavor to read a little closer and a little slower in the future. Also, what you describe with rc.local wouldn't work anyway, even if it had ben what was asked. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: best way to ensure './' is at beginning of sys.path?
On Fri, 03 Feb 2017 13:19:30 -0700, Michael Torrie wrote: > On 02/03/2017 12:07 PM, Wildman via Python-list wrote: >> Sorry, I forgot something important. If you use >> /etc/rc.local, the execute bit must be set. > > I don't think this is what Neal Becker was asking about. He's talking > about the Python module search path (sys.path) not the operating system > PATH variable. Correct me if I'm wrong. After re-reading the post I see you are correct. I will endeavor to read a little closer and a little slower in the future. -- GNU/Linux user #557453 "Well, that's quite different. Never mind." -Emily Litella -- https://mail.python.org/mailman/listinfo/python-list
Re: best way to ensure './' is at beginning of sys.path?
On 02/03/2017 12:07 PM, Wildman via Python-list wrote: > Sorry, I forgot something important. If you use > /etc/rc.local, the execute bit must be set. I don't think this is what Neal Becker was asking about. He's talking about the Python module search path (sys.path) not the operating system PATH variable. Correct me if I'm wrong. -- https://mail.python.org/mailman/listinfo/python-list
Re: best way to ensure './' is at beginning of sys.path?
On Fri, 03 Feb 2017 12:58:15 -0600, Wildman wrote: > On Fri, 03 Feb 2017 11:06:00 -0500, Neal Becker wrote: > >> I want to make sure any modules I build in the current directory overide any >> others. To do this, I'd like sys.path to always have './' at the beginning. >> >> What's the best way to ensure this is always true whenever I run python3? > > In python, this method will work but it is only in effect > for the running process that calls it while it is running. > It is not system wide and it is not permanent. > > import os > os.environ["PATH"] = os.environ["PATH"] + ":./" > or > os.environ["PATH"] = "./:" + os.environ["PATH"] > > (assuming Linux platform) > To make it permanent for a certain user, add one of > these lines to /home/user/.profile and log out/in: > > PATH="$PATH:./" > or > PATH="./:$PATH" > > To make it permanent for all users, add one of > these pairs of lines to /etc/rc.local and reboot: > > export PATH=$PATH:./ > exit 0 > or > export PATH=./:$PATH > exit 0 > > Add 'exit 0' only if it doesn't exist already and it > must be the last line. If /etc/rc.local does not > exist, create it. Sorry, I forgot something important. If you use /etc/rc.local, the execute bit must be set. -- GNU/Linux user #557453 The cow died so I don't need your bull! -- https://mail.python.org/mailman/listinfo/python-list
Re: best way to ensure './' is at beginning of sys.path?
On Fri, 03 Feb 2017 11:06:00 -0500, Neal Becker wrote: > I want to make sure any modules I build in the current directory overide any > others. To do this, I'd like sys.path to always have './' at the beginning. > > What's the best way to ensure this is always true whenever I run python3? In python, this method will work but it is only in effect for the running process that calls it while it is running. It is not system wide and it is not permanent. import os os.environ["PATH"] = os.environ["PATH"] + ":./" or os.environ["PATH"] = "./:" + os.environ["PATH"] (assuming Linux platform) To make it permanent for a certain user, add one of these lines to /home/user/.profile and log out/in: PATH="$PATH:./" or PATH="./:$PATH" To make it permanent for all users, add one of these pairs of lines to /etc/rc.local and reboot: export PATH=$PATH:./ exit 0 or export PATH=./:$PATH exit 0 Add 'exit 0' only if it doesn't exist already and it must be the last line. If /etc/rc.local does not exist, create it. -- GNU/Linux user #557453 The cow died so I don't need your bull! -- https://mail.python.org/mailman/listinfo/python-list
Re: Meta: mailing list, bounces, and SPF?
On 03/02/2017 18:15, Tim Chase wrote: However, despite seeing messages appearing in the online archives, I'm not receiving anything via email. When I send a "subscribe" message to mailman, it responds telling me that I'm already subscribed (and checking the settings on the web interface confirm that everything should be flowing). Your email address had been tagged to receive no mail because of the bounces mailman was getting. (At least, I think that's what it was). I've cleared that now so you should be getting new emails via the list -- including this one! TJG -- https://mail.python.org/mailman/listinfo/python-list
Meta: mailing list, bounces, and SPF?
Thanks to an abysmal failure of my hosting service (Site5), I was without email for multiple days, and when it came back up, the SPF record was pointed at the wrong place. I normally get a steady stream of comp.lang.python/python-list@ messages at my email address, so when they/I finally got things sorted out, I expected a backlog of a week's worth of c.l.p email, or at least for the mail to resume flowing. However, despite seeing messages appearing in the online archives, I'm not receiving anything via email. When I send a "subscribe" message to mailman, it responds telling me that I'm already subscribed (and checking the settings on the web interface confirm that everything should be flowing). Is there something I've missed to get the messages flowing again? Thanks, -tkc PS: for obvious reasons, please CC me. -- https://mail.python.org/mailman/listinfo/python-list
best way to ensure './' is at beginning of sys.path?
I want to make sure any modules I build in the current directory overide any others. To do this, I'd like sys.path to always have './' at the beginning. What's the best way to ensure this is always true whenever I run python3? -- https://mail.python.org/mailman/listinfo/python-list
Re: Fw: Context
On 2/3/2017 8:10 AM, Antonio wrote: I have python version 3.6.0 installed into my desktop)windows 7) but the menu/context (file,edit..etc) is missing. Run IDLE (there should be a Start menu icon) or install or run another IDE. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Context
> On Feb 3, 2017, at 8:10 AM, Antonio wrote: > > From: Antonio > Sent: Friday, February 3, 2017 1:02 PM > To: python-list@python.org > Subject: Context > > I have python version 3.6.0 installed into my desktop)windows 7) but the > menu/context (file,edit..etc) is missing. > > How to fix this problem? > python, is not a GUI program, it doesn’t have a menu of actions. If you want to surround python with a GUI you would have to install any of several IDEs (Integrated Development Environments) which will let you create python programs, edit them, and test them interactively. Not being a Windows user, I shouldn't recommend any particular one. Bill > > Thanks > > > Antonio > > > > [cid:36574bcd-0958-41f0-a1b3-2c34586b236a] > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Numpy and Scipy for Python3.5
Can I find those modules in the FreeBSD ports? -- https://mail.python.org/mailman/listinfo/python-list
Re: PyDictObject to NSDictionary
On 2/2/17 6:30 PM, Charles Heizer wrote: Hello, I'm embedding python in to my Objective-C app and I need to know how do I convert a PyDictObject (PyObject) to a NSDictionary? Thanks! Does the PyObjC library provide any support for this? It allows integration between the Cocoa API's and Python. --Kevin -- 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
Fw: Context
From: Antonio Sent: Friday, February 3, 2017 1:02 PM To: python-list@python.org Subject: Context I have python version 3.6.0 installed into my desktop)windows 7) but the menu/context (file,edit..etc) is missing. How to fix this problem? Thanks Antonio [cid:36574bcd-0958-41f0-a1b3-2c34586b236a] -- https://mail.python.org/mailman/listinfo/python-list
Get Result based on the Top value
Hello guys,
Here i am creating a GUI which will act as a search engine.
When you search for a data in search box it will fetch the results from the
very first page in browser and it is displayed in a Text widget
When the TOP value is 10 it should display only the first 10 results based on
numbers.if it is 20 it should display first 20 results based on the number.
How should i do that?
Here is my script
from Tkinter import *
import mechanize
from bs4 import BeautifulSoup
root = Tk()
def clear_search():#Reset the search field
Search.delete(0,END)
Result.delete("1.0",END)
def fun(self=0):
new = Search.get()
url = "https://duckduckgo.com/";
br = mechanize.Browser()
br.set_handle_robots(False)
br.open(url)
br.select_form(name="x")
br["q"] = str(new)
res = br.submit()
content = res.read()
#print content
soup = BeautifulSoup(content,"html.parser")
mylink = soup.find_all('a')
v = 0
for i in mylink:
try:
if i.attrs['class'][0] == "result__a":
v = v + 1
Result.insert(END,v)
Result.insert(END,i.text)
Result.insert(END,'\n')
elif i.attrs['class'][0] == "result__snippet":
Result.insert(END,i.text)
Result.insert(END,'\n')
Result.insert(END,i.attrs['href'])
Result.insert(END,'\n ')
Result.insert(END,'--')
except KeyError:
pass
with open("result1.xls", "w") as f:
f.write(content)
Value = Label(root,text="Value:", font="-weight bold")
Value.grid(row=0,column=0,padx=15)
Search = Entry(root,width=50)
Search.grid(row=0,column=1)
Top = Label(root,text="TOP",font="-weight bold")
Top.grid(row=1,column=0)
var = StringVar(root)
var.set('10')
Dropdownlist = OptionMenu(root,var,'10','20','50','100')
Dropdownlist.grid(row=1,column=1,sticky="w")
Go = Button(root,text="GO",width=5,command=fun)
Go.bind("",fun)
Go.grid(row=1,column=1)
Reset = Button(root,text="RESET",width=5,command=clear_search)
Reset.grid(row=1,column=1,sticky="e")
Result = Text(root,height=20,width=75)
Result.grid(row=2,column=1,padx=50,pady=10)
Scroll = Scrollbar(root,command=Result.yview)
Scroll.grid(row=2,column=2,sticky=N+S)
Result.config(yscrollcommand=Scroll.set)
root.mainloop()
--
https://mail.python.org/mailman/listinfo/python-list
Interpolation gives negative values
Dear all, I have an ASCII file (f1) with 100M lines with columns x,y,z ( new data points) and then I have a second ASCII file (f2) with 2M lines with columns x,y,z and VALUE (v10).(known data points). I need to interpolate f1 over f2, that is I need to have values for v10 for all coordinated in f1. I am using the following script to interpolate. from scipy.interpolate import NearestNDInterpolator #new data points f1=np.loadtxt(os.path.join(dir,coord_source),delimiter=None,skiprows=0) x_coord=f1[:,1] y_coord=f1[:,2] z_coord=f1[:,3] # known data points f2=np.loadtxt(os.path.join(dir,val_source),delimiter=None,skiprows=1) x_val=f2[:,1] y_val=f2[:,2] z_val=f2[:,3] v10=f2[:,10] # Value to be interpolated # my interpolation function myf_v10=NearestNDInterpolator((x_val, y_val,z_val),v10) interpolated_v10=myf_v10(x_coord,y_coord,z_coord) I have the following questions. 1. Considering f1 is 50 times bigger than f2. can I still use the above script? 2. The variable v10 that I need to interpolate should always be >= 0 (positive). Using the above script I am getting negative values for v10. How can I fix this? I would really appreciate your help, Thanks in Advance, -- https://mail.python.org/mailman/listinfo/python-list
