Re: Recompilation of Python3.6.x
On Thu, Mar 23, 2017 at 10:50 AM, Nathan Ernst wrote: > I would also add a link to the dependency's project page, in case building > from source is necessary. > > You don't always have root, and you're not always building with the system > supplied compiler. > > There are a lot of situations that may require building from source. Far > too many to even bother to enumerate. If you're building a large project from source and are not using a system-provided compiler, you should have enough experience with building stuff from source that you can track libraries down yourself. Conversely, if you don't have that experience, why in the world are you not using a provided compiler? You don't need admin access to install a compiler on Windows. On Linux, you can generally replicate the environment somewhere else (unless you're trying to build for some really unusual CPU, in which case, again, you should first have enough experience to do it manually), build using the normal methods, and then carry the binary up to the restricted system. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Recompilation of Python3.6.x
I would also add a link to the dependency's project page, in case building from source is necessary. You don't always have root, and you're not always building with the system supplied compiler. There are a lot of situations that may require building from source. Far too many to even bother to enumerate. On Wed, Mar 22, 2017 at 6:23 PM, Jon Ribbens wrote: > On 2017-03-22, Grant Edwards wrote: > > On 2017-03-22, Thomas Nyberg wrote: > >> On 03/22/2017 03:22 PM, Jon Ribbens wrote: > >>> A simple table with a list of the library names, the debian package > >>> names, and the rpm names would provide the information in a way that > >>> would be useful to everyone. > > > > A _simple_ table would be useful. However, a _simple_ table is not > > possible. > > > >> I definitely agree, but it would be kind of difficult to maintain. I > >> mean if you supported debian and redhat (should others be > >> considered?), > > > > And you would need table for each _version_ of each distribution > > (libraries sometimes get combined/renamed/split). > > Not really, that's why I suggested one of the fields in the table > would be the standard library name - people should always be able > to use that to find the appropriate package for their distribution > (if there is one, otherwise they'll need to compile from source). > > > And you would need tables showing which libraires are required for > > which Python features: tkinter is optional, crypto is optional (or at > > least used to be), etc. > > That's a good idea - that would make the simple table have 4 columns: > name, deb, rpm, python module (or "essential"). > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Recompilation of Python3.6.x
On 2017-03-22, Grant Edwards wrote: > On 2017-03-22, Thomas Nyberg wrote: >> On 03/22/2017 03:22 PM, Jon Ribbens wrote: >>> A simple table with a list of the library names, the debian package >>> names, and the rpm names would provide the information in a way that >>> would be useful to everyone. > > A _simple_ table would be useful. However, a _simple_ table is not > possible. > >> I definitely agree, but it would be kind of difficult to maintain. I >> mean if you supported debian and redhat (should others be >> considered?), > > And you would need table for each _version_ of each distribution > (libraries sometimes get combined/renamed/split). Not really, that's why I suggested one of the fields in the table would be the standard library name - people should always be able to use that to find the appropriate package for their distribution (if there is one, otherwise they'll need to compile from source). > And you would need tables showing which libraires are required for > which Python features: tkinter is optional, crypto is optional (or at > least used to be), etc. That's a good idea - that would make the simple table have 4 columns: name, deb, rpm, python module (or "essential"). -- https://mail.python.org/mailman/listinfo/python-list
Re: python source code
On 22/03/17 21:57, M. R.P. wrote: does anyone know were I can [find?] python source code programs? Are you looking for the source to a Python language implementation itself? If so, see this link: https://www.python.org/downloads/ If not, what are you looking for, exactly? What sort of Python programs? E. -- https://mail.python.org/mailman/listinfo/python-list
Re: python source code
On 03/22/2017 05:57 PM, M. R.P. wrote: does anyone know were I can python source code programs? The source code for cpython (i.e. the most common interpreter) can be found here: https://www.python.org/downloads/source/ https://github.com/python/cpython Unless you mean the source of a specific python program...then it depends on the program and we'll need a bit more detail... Cheers, Thomas -- https://mail.python.org/mailman/listinfo/python-list
python source code
does anyone know were I can python source code programs? -- https://mail.python.org/mailman/listinfo/python-list
Re: Recompilation of Python3.6.x
On Thu, Mar 23, 2017 at 7:34 AM, Thomas Nyberg wrote: > On 03/22/2017 03:22 PM, Jon Ribbens wrote: >> >> A simple table with a list of the library names, the debian package >> names, and the rpm names would provide the information in a way that >> would be useful to everyone. >> > > I definitely agree, but it would be kind of difficult to maintain. I mean if > you supported debian and redhat (should others be considered?), then who's > responsibility is it to keep it up to date? And then for Macs would you use > names from brew? For Windows what would be done there? Other systems? I > might be over complicating things, but still it feels like this could > quickly fall out of date (though I guess new libraries are introduced pretty > rarely, so maybe this is an unfounded fear). This is exactly what apt build-dep is. It's part of the package manager system, so it's tied to your own version of Debian/Ubuntu/etc, and it's usually pretty reliable. You ask for the build deps of a previous Python 3, and they'll generally be what you need for the latest. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Recompilation of Python3.6.x
On 2017-03-22, Thomas Nyberg wrote: > On 03/22/2017 03:22 PM, Jon Ribbens wrote: >> A simple table with a list of the library names, the debian package >> names, and the rpm names would provide the information in a way that >> would be useful to everyone. A _simple_ table would be useful. However, a _simple_ table is not possible. > I definitely agree, but it would be kind of difficult to maintain. I > mean if you supported debian and redhat (should others be > considered?), And you would need table for each _version_ of each distribution (libraries sometimes get combined/renamed/split). And you would need tables showing which libraires are required for which Python features: tkinter is optional, crypto is optional (or at least used to be), etc. -- Grant Edwards grant.b.edwardsYow! FUN is never having to at say you're SUSHI!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Recompilation of Python3.6.x
On 03/22/2017 03:22 PM, Jon Ribbens wrote: A simple table with a list of the library names, the debian package names, and the rpm names would provide the information in a way that would be useful to everyone. I definitely agree, but it would be kind of difficult to maintain. I mean if you supported debian and redhat (should others be considered?), then who's responsibility is it to keep it up to date? And then for Macs would you use names from brew? For Windows what would be done there? Other systems? I might be over complicating things, but still it feels like this could quickly fall out of date (though I guess new libraries are introduced pretty rarely, so maybe this is an unfounded fear). It's a bit hypothetical anyway. I guess if someone started gathering all of this information it could maybe be added? If not directly into the actual repository then maybe somewhere on the main python website. Having this would definitely be great, but I know I personally don't feel like doing the legwork... Cheers, Thomas -- https://mail.python.org/mailman/listinfo/python-list
Re: Recompilation of Python3.6.x
On 03/22/2017 06:34 PM, Thomas Nyberg wrote: On 03/22/2017 12:42 PM, Klaus Jantzen wrote: Hello, in order to have the Python-SQLite support available one has to recompile Python. For the recompiliation to succeed a number of 'modules/libs' have to be present. In the internet I found the following list build-essential libz-dev libreadline-dev libncursesw5-dev libssl-dev libgdbm-dev libsqlite3-dev libbz2-dev liblzma-dev tk-dev libdb-dev libc6-dev zlib After having installed these 'modules/libs' I recompiled Python3.6.1 and although the steps 'make', 'make test', and 'make install' produced some errors the sqlite3-support is available. My question: Is this list complete or are there superfluous items? My suggestion: Couldn't such a list be provided in the README file? If you're using Ubuntu/debian, you could use `sudo apt-get build-dep python3.5` (might need another version depending upon what you have in your package manager). What that does is install the packages required to build the debian packages. Unless any new libraries are needed for 3.6, you should be good. I did not know somenthing like this exists. I can't speak for the maintainers, but I don't think that providing such a list is super reasonable considering that there are many different OSs which have sometimes have slightly different library package names (though of course one could argue that Ubuntu/debian helps a lot of people). Cheers, Thomas With the above my suggestion is superfluous. Thanks a lot for the information. -- K.D.J. -- https://mail.python.org/mailman/listinfo/python-list
Re: Recompilation of Python3.6.x
On 2017-03-22, Thomas Nyberg wrote: > I can't speak for the maintainers, but I don't think that providing such > a list is super reasonable considering that there are many different OSs > which have sometimes have slightly different library package names > (though of course one could argue that Ubuntu/debian helps a lot of people). A simple table with a list of the library names, the debian package names, and the rpm names would provide the information in a way that would be useful to everyone. -- https://mail.python.org/mailman/listinfo/python-list
Re: Recompilation of Python3.6.x
On 03/22/2017 12:42 PM, Klaus Jantzen wrote: Hello, in order to have the Python-SQLite support available one has to recompile Python. For the recompiliation to succeed a number of 'modules/libs' have to be present. In the internet I found the following list build-essential libz-dev libreadline-dev libncursesw5-dev libssl-dev libgdbm-dev libsqlite3-dev libbz2-dev liblzma-dev tk-dev libdb-dev libc6-dev zlib After having installed these 'modules/libs' I recompiled Python3.6.1 and although the steps 'make', 'make test', and 'make install' produced some errors the sqlite3-support is available. My question: Is this list complete or are there superfluous items? My suggestion: Couldn't such a list be provided in the README file? If you're using Ubuntu/debian, you could use `sudo apt-get build-dep python3.5` (might need another version depending upon what you have in your package manager). What that does is install the packages required to build the debian packages. Unless any new libraries are needed for 3.6, you should be good. I can't speak for the maintainers, but I don't think that providing such a list is super reasonable considering that there are many different OSs which have sometimes have slightly different library package names (though of course one could argue that Ubuntu/debian helps a lot of people). Cheers, Thomas -- https://mail.python.org/mailman/listinfo/python-list
Recompilation of Python3.6.x
Hello, in order to have the Python-SQLite support available one has to recompile Python. For the recompiliation to succeed a number of 'modules/libs' have to be present. In the internet I found the following list build-essential libz-dev libreadline-dev libncursesw5-dev libssl-dev libgdbm-dev libsqlite3-dev libbz2-dev liblzma-dev tk-dev libdb-dev libc6-dev zlib After having installed these 'modules/libs' I recompiled Python3.6.1 and although the steps 'make', 'make test', and 'make install' produced some errors the sqlite3-support is available. My question: Is this list complete or are there superfluous items? My suggestion: Couldn't such a list be provided in the README file? -- K.D.J. -- https://mail.python.org/mailman/listinfo/python-list
ANN: Wing Python IDE 6.0.3 released
Hi, We've just released Wing 6.0.3 which implements auto-completion in strings and comments, supports syntax highlighting and error indicators for f-strings, adds a How-To for Jupyter notebooks, allows concurrent update of recent menus from multiple instances of Wing, fixes Django template debugging, and makes about 70 other improvements. For details, see http://wingware.com/pub/wingide/6.0.3/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 for Wing Pro, and makes Wing Personal free. 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 more detailed overview of new features see the release notice at http://wingware.com/news/2017-03-21 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/ 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 development, 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 Jupyter, Django, and others), find symbol in project, and other features. Links Release notice: http://wingware.com/news/2017-03-21 Download: http://wingware.com/downloads 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
Announcing SCM Workbench 0.8.5 GUI for Git, Mercurial (hg) and Subversion (svn)
SCM Workbench features • Support Subversion (svn), Mercurial (hg) and Git projects. • Easy to learn and use • Built in User Guide describes the operation and features of the application. • Add project wizard can scan for all your existing projects. • All subversion client operations in a GUI • Many Git client operations in a GUI • GUI git rebase • Some mercurial (hg) client operations in a GUI • Enhanced operations (subversion rename of modified files etc) • Support software development workflow • Built in GUI diff showing line and character diffs • Ability to diff between commits in a files history • Runs on Windows, Mac OS X and Unix platforms Kits are available for Windows, macOS and Fedora. Please visit http://scm-workbench.barrys-emacs.org/ for downloads and further information on SCM Workbench. SCM Workbench is implemented in Python3 using PyQt5, pysvn, GitPython and hglib-python. Barry -- https://mail.python.org/mailman/listinfo/python-list
Re: Manager for project templates, that allows "incremental" feature addition
Paul Moore writes: > I'm looking for a utility that is something like cookiecutter, in that it > generates a "template" project for me. However, I would like the ability to > have a template add content based on runtime questions, something like > >Do you want to include a C extension? [yes/no] >... adds Extension() to setup.py, adds a C source file, etc >Do you want to include tests? [yes/no] >... add a test directory with a sample test >Tests to run under tox? [yes/no] >... add tox support (this question shouldn't be asked if the previous > answer was "no") > > As far as I know, this sort of feature isn't available in cookiecutter, nor > is it planned. > > Does anyone know of any similar utility that has this feature? This what I wrote and heavily use https://pypi.python.org/pypi/metapensiero.tool.tinject It seems to fit some, but not all, of your requested features. Hope this helps, ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. l...@metapensiero.it | -- Fortunato Depero, 1929. -- https://mail.python.org/mailman/listinfo/python-list
