Re: [AstroPy] ANN: Astropy v0.4 released
Hello, From the User Documentation page I've noticed that the pdf version of the docs just produces this 1-page output: https://media.readthedocs.org/pdf/astropy/stable/astropy.pdf The other docs (html and epub) seem to be fine. Cheers, Angelo Erik Tollerud wrote: Hello, We are very happy to announce the third major public release (v0.4) of the astropy package, a core Python package for Astronomy: http://www.astropy.org Astropy is a community-driven package intended to contain much of the core functionality and common tools needed for performing astronomy and astrophysics with Python. New and improved major functionality in this release includes: * A new astropy.vo.samp sub-package adapted from the previously standalone SAMPy package * A re-designed astropy.coordinates sub-package for celestial coordinates * A new ‘fitsheader’ command-line tool that can be used to quickly inspect FITS headers * A new HTML table reader/writer * Improved performance for Quantity objects * A re-designed configuration framework In addition, hundreds of smaller improvements and fixes have been made. An overview of the changes is provided at: http://docs.astropy.org/en/latest/whatsnew/0.4.html Instructions for installing Astropy are provided at the http://www.astropy.org website, and extensive documentation can be found at: http://docs.astropy.org In particular, if you use Anaconda, you can update to v0.4 with: conda update astropy Please report any issues, or request new features via our GitHub repository: https://github.com/astropy/astropy/issues Over 80 developers have contributed code to Astropy so far, and you can find out more about the team behind Astropy here: http://www.astropy.org/team.html If you use Astropy directly - or as a dependency to another package - for your work, please remember to include the following acknowledgment at the end of papers: This research made use of Astropy, a community-developed core Python package for Astronomy (Astropy Collaboration, 2013). where “(Astropy Collaboration, 2013)” is the Astropy paper which was published last year: http://adsabs.harvard.edu/abs/2013A%26A...558A..33A Please feel free to forward this announcement to anyone you think might be interested in this release. We hope that you enjoy using Astropy as much as we enjoyed developing it! Thomas Robitaille, Erik Tollerud, and Perry Greenfield on behalf of The Astropy Collaboration ___ AstroPy mailing list astr...@scipy.org http://mail.scipy.org/mailman/listinfo/astropy -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: OT: usenet reader software
Martin S shieldf...@gmail.com: Is there a point to still use Usenet? Last time I checked noise overwhelmed signal by a factor of something close to 542. Well, here you are at URL: news:comp.lang.python, in the middle of all that noise. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
On Sat, Jul 19, 2014 at 4:10 PM, Marko Rauhamaa ma...@pacujo.net wrote: Martin S shieldf...@gmail.com: Is there a point to still use Usenet? Last time I checked noise overwhelmed signal by a factor of something close to 542. Well, here you are at URL: news:comp.lang.python, in the middle of all that noise. Or at python-list@python.org - a lot of the newsgroup spam simply doesn't make it across the bridge. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
Chris Angelico ros...@gmail.com: On Sat, Jul 19, 2014 at 4:10 PM, Marko Rauhamaa ma...@pacujo.net wrote: Martin S shieldf...@gmail.com: Is there a point to still use Usenet? Last time I checked noise overwhelmed signal by a factor of something close to 542. Well, here you are at URL: news:comp.lang.python, in the middle of all that noise. Or at python-list@python.org - a lot of the newsgroup spam simply doesn't make it across the bridge. Spam? What spam? There's a lot of hot air but I have yet to encounter spam. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
On Sat, Jul 19, 2014 at 4:51 PM, Marko Rauhamaa ma...@pacujo.net wrote: Chris Angelico ros...@gmail.com: On Sat, Jul 19, 2014 at 4:10 PM, Marko Rauhamaa ma...@pacujo.net wrote: Martin S shieldf...@gmail.com: Is there a point to still use Usenet? Last time I checked noise overwhelmed signal by a factor of something close to 542. Well, here you are at URL: news:comp.lang.python, in the middle of all that noise. Or at python-list@python.org - a lot of the newsgroup spam simply doesn't make it across the bridge. Spam? What spam? There's a lot of hot air but I have yet to encounter spam. That means you have good filtering. There are several levels of spam filtering happening. Fortunately, they do a pretty good job of catching most of it; I occasionally see junk mail on the list, but most of it gets caught and discarded. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Python and IDEs [was Re: Python 3 is killing Python]
Earlier, I mentioned a considerable number of IDEs which are available for Python, including: PyDev, Eric, Komodo, PyCharm, WingIDE, SPE, Ninja-IDE, Geany, IEP, Spyder, Boa Constructor, PyScripter, NetBeans, Emacs, KDevelop, and BlackAdder. https://wiki.python.org/moin/IntegratedDevelopmentEnvironments There is also IDLE, which is part of the standard Python installation, as well as my preference: Unix/Linux as an IDE. http://blog.sanctum.geek.nz/series/unix-as-ide/ http://michaelochurch.wordpress.com/2013/01/09/ide-culture-vs-unix-philosophy/ Some people ask: How many of those quality IDEs ship with Python? Most don't, of course, since they are third-party tools. Not that it matters: it's 2014, not 1974, and anyone in the developed world interested in computer programming has easy access to the information superhighway sometimes know as the Internet. (Many people in developing nations also have access to the Internet, and those who don't probably have bigger problems to worry about.) With the Internet, most of these IDEs are normally just a few clicks away. People using Linux will generally find that they can install some of these IDEs using their package manager. For example, Red Hat Linux based systems such on Centos or Fedora can use the yum package manager, e.g.: yum install geany geany-plugins while Debian and Ubuntu based systems (such as Mint) can use apt-get or aptitude, e.g.: aptitude install eric apt-get install spe Of course, most Linux distros include a GUI front-end to their package manager, but frankly if you're programming on Linux and you're unwilling to use the command line, you're making life harder for yourself than it need be. Windows and OS X users, sadly, miss out on the power of an integrated package manager. OS X have a couple of third-party packaging systems, MacPorts and Homebrew: http://www.macports.org/ http://brew.sh/ Unfortunately, software development on Windows is something of a ghetto, compared to the wide range of free tools available for Linux. Outside of a few oases like Microsoft's own commercial development tools, it's hard to do development on Windows. Hard, but not impossible, of course, and there are quite a few resources available for the Windows user willing to download installers from the Internet. For Python users, the IDEs from Wingware and Activestate are notable: https://wingware.com/ http://komodoide.com/ Some people are under the impression that IDEs are mostly or even solely for the benefit of newbies or n00bs. That's a gross misunderstanding of the situation: the average newbie is likely to be happy writing code using Notepad, or whatever bare-bones text editor they're used to, and may not even know what an IDE is. It's those with some experience in programming (particularly in the Java and Visual Basic worlds) who are more likely to expect an IDE. Another patronising view is that those who are new to programming are automatically too incompetent or ignorant to download or install an IDE without hand-holding. Even if that were the case, there is no shortage of hand-holding available on the Internet, with dozens or hundreds of forums, mailing lists, tutorial, videos and blogs offering to help. (It is undeniable that the quality of these is *extremely* variable, but that's another story.) This is the Internet generation, if software has a downloadable installer, or can be installed using a package manager, most people can deal with it, and those who can't have many opportunities to learn. (It's probably a bit much to expect the average newbie to install software from source, especially on Windows which doesn't come with much in the way of compilers and other development tools, but still, it has to be said that if you're hoping to become a programmer, installing software from source is one of the skills you should learn.) So why does Python ship with IDLE? It's not because Python requires an IDE, or that newbies need one, or that there aren't alternatives. The biggest reason for Python shipping with an IDE is not that people are unable to install alternatives, but that a lot of people are *prohibited* from doing so. For those of us who have control over our computing environment, it's all too easy to forget that a lot of people (e.g. students using school computers, or people in corporate environments where the desktops are locked down to a standard operating environment) aren't able to install the IDE of their choice. It's relatively easy to get Python itself approved -- on many systems, Python comes pre-installed -- but trying to get approval to also install third-party software is difficult or impossible. It is for the sake of those people, people who prefer or require an IDE but don't have the choice to install third-party software, that Python ships with a minimal but usable IDE. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
Chris Angelico ros...@gmail.com: On Sat, Jul 19, 2014 at 4:51 PM, Marko Rauhamaa ma...@pacujo.net wrote: There's a lot of hot air but I have yet to encounter spam. That means you have good filtering. Interesting. Who's filtering comp.lang.python? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
On Sat, Jul 19, 2014 at 5:32 PM, Marko Rauhamaa ma...@pacujo.net wrote: Chris Angelico ros...@gmail.com: On Sat, Jul 19, 2014 at 4:51 PM, Marko Rauhamaa ma...@pacujo.net wrote: There's a lot of hot air but I have yet to encounter spam. That means you have good filtering. Interesting. Who's filtering comp.lang.python? Possibly your provider, possibly your client, hard to say. But I'm pretty confident you do NOT see all the spam that goes through, because it's definitely there. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Pip doesn't install my scripts
Hi, I am trying to package my file, but I am having problems with installing my Scripts. Here is my package: https://github.com/yasar11732/tklsystem Here is my package's PyPi page: https://pypi.python.org/pypi/TkLsystem The problem I face is that, when I run `python setup.py install` from my development directory, I see that script file is installed. However, if I run `pip install TkLsystem`, my script file is not copied to Scripts directory. What am I doing wrong here? -- http://ysar.net/ -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
Chris Angelico ros...@gmail.com: On Sat, Jul 19, 2014 at 5:32 PM, Marko Rauhamaa ma...@pacujo.net wrote: Interesting. Who's filtering comp.lang.python? Possibly your provider, possibly your client, hard to say. But I'm pretty confident you do NOT see all the spam that goes through, because it's definitely there. Well, anyway, spam is not a reason to avoid comp.lang.python. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Java
On Jul 18, 2014, at 8:19 PM, Dan Stromberg drsali...@gmail.com wrote: There's comp.lang.java if you have an NNTP feed. There are also the OpenJDK mailing lists. I had a Java problem once - I'd decided to recode one of my Python scripts into Java, just to demonstrate to myself that I could do it. I asked about the problem on comp.lang.java, and I got a handful of irrelevant responses. Posting to an OpenJDK list got me a solution pretty quickly though. The OpenJDK lists are a bit more focused on specific areas of OpenJDK than comp.lang.python is; you could end up subscribing to several of them to get the same effect. Thanks Dan! I checked out the OpenJDK mailing lists they’re a little confusing but I’m sure I can find something. Thanks for the suggestions! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3.4.1 64 bit Version
On Sat, Jul 19, 2014 at 1:23 AM, Terry Reedy tjre...@udel.edu wrote: On 7/18/2014 2:56 PM, Chris “Kwpolska” Warrick wrote: It’s also slightly easier to find pre-made binaries for 32-bit than 64-bit. Searching 'python windows binaries' on Google and the first hit is http://www.lfd.uci.edu/~gohlke/pythonlibs/ This page provides 32- and 64-bit Windows binaries of many scientific open-source extension packages for the official CPython distribution of the Python programming language. He or they are currently compiling both 32 and 64 bits binaries for 2.7, 3.3, and 3.4. I know that site, but its binaries are not used by `pip` while wheels published on PyPI are — and those wheels are not always available for 64-bit. -- Chris “Kwpolska” Warrick http://chriswarrick.com/ PGP: 5EAAEA16 stop html mail | always bottom-post | only UTF-8 makes sense -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip doesn't install my scripts
On Sat, Jul 19, 2014 at 9:19 AM, Yaşar Arabacı yasar11...@gmail.com wrote: Hi, I am trying to package my file, but I am having problems with installing my Scripts. Here is my package: https://github.com/yasar11732/tklsystem Here is my package's PyPi page: https://pypi.python.org/pypi/TkLsystem The problem I face is that, when I run `python setup.py install` from my development directory, I see that script file is installed. However, if I run `pip install TkLsystem`, my script file is not copied to Scripts directory. What am I doing wrong here? -- http://ysar.net/ -- https://mail.python.org/mailman/listinfo/python-list Tons of things are wrong. * SyntaxError: Non-ASCII character '\xc5' in file lsystem/__init__.py on line 6, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details * you should not import your package in setup.py * you are python 3-only for no real reason at all * the zip on PyPI is for version 0.1.3. It ignores the version 0.1-5, because of the dash, which should not be used in names of stable software * and, most importantly, you’re doing things using ancient methods. Upgrade your setup.py to use setuptools, and its entry points mechanism. I’ve sent a PR to fix all of your errors: https://github.com/yasar11732/tklsystem/pull/1 -- Chris “Kwpolska” Warrick http://chriswarrick.com/ PGP: 5EAAEA16 stop html mail | always bottom-post | only UTF-8 makes sense -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
memilanuk memila...@gmail.com wrote: Guess where I'm going with this is... is there anything out there worth trying - on Linux - that I'm missing? If slrn was a maybe then there's also tin for text mode news readers, it's what I have always used. I don't know what it does with HTML as none of the groups I frequent ever have any HTML in them. It does add one 'GUIness' to its text mode, it's mouse aware so you can click on messages in a list to open them. -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
Sturla Molden sturla.mol...@gmail.com wrote: Guess where I'm going with this is... is there anything out there worth trying - on Linux - that I'm missing? leafnode That doesn't address the problem at all! :-) You still need a news reader. -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list
Confused with Functions and decorators
Ok so i am trying to learn this and i do not understand some of it. I also tried to searched the web but i couldnt find any answers. 1. I dont understand when i will need to use a function that returns another function. eg def outer(): def inner(): x = 5 return inner why not just use inner and forget about the whole outer function? 2. This is more yes or no question when you pass in a func into another func as a parameter do you need to specify the parameter that the func is being passed into as func? eg def passinto(func) pass def param(): x = 5 p = passinto(param) also is this above statement correct? -- https://mail.python.org/mailman/listinfo/python-list
Re: Confused with Functions and decorators
On Sat, Jul 19, 2014 at 8:52 PM, Jerry lu nicholascann...@gmail.com wrote: Ok so i am trying to learn this and i do not understand some of it. I also tried to searched the web but i couldnt find any answers. 1. I dont understand when i will need to use a function that returns another function. eg def outer(): def inner(): x = 5 return inner why not just use inner and forget about the whole outer function? 2. This is more yes or no question when you pass in a func into another func as a parameter do you need to specify the parameter that the func is being passed into as func? eg def passinto(func) pass def param(): x = 5 p = passinto(param) also is this above statement correct? In Python, a function is a real thing, on par with integers, lists, modules, files, etc. You can create them, dispose of them, pass them as parameters, receive them as return values, store them in lists, everything. When you call outer(), it creates a function (which does nothing useful, and then returns None) and returns a reference to it. And yes, in that case, there's no particular value in that setup; but an inner function can be a closure (you can look that up later): def outer(x): def inner(y): return x + y return inner The x inside inner() will refer to the x that was in scope when it was created, so you can call outer() several times with different arguments and get back different functions that do different things. Since functions are objects of equal standing to any other (called first-class objects - look that up too), you can pass them as parameters just the same as you would any other type of object. There's no reason to call an integer 'i', so there's no reason to call a function 'func'. You can if you like, but it'll work the same regardless. There is no magic happening here. None of this has anything to do with decorators, though. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Confused with Functions and decorators
oh yeah i forgot about the decorators. Um say that you wanted to decorate a function with the outer() func you would just put @outer on top of it? And this is the same as passing another func into the outer func? and also with the first example you say x is in the scope when is was created can you define x in the outer func and refer to it in the inner func? -- https://mail.python.org/mailman/listinfo/python-list
Re: Confused with Functions and decorators
On Sat, Jul 19, 2014 at 9:40 PM, Jerry lu nicholascann...@gmail.com wrote: oh yeah i forgot about the decorators. Um say that you wanted to decorate a function with the outer() func you would just put @outer on top of it? And this is the same as passing another func into the outer func? and also with the first example you say x is in the scope when is was created can you define x in the outer func and refer to it in the inner func? Firstly, please don't use Google Groups, or if you must, please clean up its messes. It's conventional on mailing lists and newsgroups to quote a bit of text to give context; so, for instance, you mention one of my examples, without quoting it. Secondly: Don't worry about decorators. You almost never need them, and they're very simple. (Python avoids magic whenever it can!) These two are equivalent: def inner(): pass inner = outer(inner) @outer def inner(): pass That's all the decorator does. It's that simple. As to scoping... read up on closures. There's a lot that I could say, but you'll find some excellent articles on the internet about it. Also, you'll learn how to find information, which is a skill you are going to need in this life :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-2.6.1 ctypes test cases failing
libffi fails on cavium for python 2.7 ctypes still doesnt build :(O On Wednesday, 7 March 2012 11:25:59 UTC-8, Terry Reedy wrote: On 3/7/2012 12:43 PM, Naresh Bhat wrote: Hi All, I have the following setup Kernel version: linux-2.6.32.41 Python Version: Python-2.6.1 Hardware target: MIPS 64bit I am just trying to run python test cases, Observed that on my MIPS 64bit system only _ctypes related test cases are failing. Is there any available patch for this issue ?? There have been patches to ctypes since 2.6.1. At minimum, you should be using the latest version of 2.6. Even better, perhaps, would be the latest version of 2.7, since it contain patches applied after 2.6 went to security fixes only. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Confused with Functions and decorators
Ok thanks man I have never used forums and stuff before but it is great help thank you so much. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip doesn't install my scripts
Hi Chris, Thanks a lot for your fixes. I have merged your PR and updated PyPi package. I have one more question; is it documented somewhere that one shouldn't use dash for stable version names? I am not professional in programming and I thought for some reason that release numbers should be separated with dashes. 2014-07-19 12:44 GMT+03:00 Chris “Kwpolska” Warrick kwpol...@gmail.com: On Sat, Jul 19, 2014 at 9:19 AM, Yaşar Arabacı yasar11...@gmail.com wrote: Hi, I am trying to package my file, but I am having problems with installing my Scripts. Here is my package: https://github.com/yasar11732/tklsystem Here is my package's PyPi page: https://pypi.python.org/pypi/TkLsystem The problem I face is that, when I run `python setup.py install` from my development directory, I see that script file is installed. However, if I run `pip install TkLsystem`, my script file is not copied to Scripts directory. What am I doing wrong here? -- http://ysar.net/ -- https://mail.python.org/mailman/listinfo/python-list Tons of things are wrong. * SyntaxError: Non-ASCII character '\xc5' in file lsystem/__init__.py on line 6, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details * you should not import your package in setup.py * you are python 3-only for no real reason at all * the zip on PyPI is for version 0.1.3. It ignores the version 0.1-5, because of the dash, which should not be used in names of stable software * and, most importantly, you’re doing things using ancient methods. Upgrade your setup.py to use setuptools, and its entry points mechanism. I’ve sent a PR to fix all of your errors: https://github.com/yasar11732/tklsystem/pull/1 -- Chris “Kwpolska” Warrick http://chriswarrick.com/ PGP: 5EAAEA16 stop html mail | always bottom-post | only UTF-8 makes sense -- http://ysar.net/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Confused with Functions and decorators
On 19/07/14 11:52, Jerry lu wrote:
Ok so i am trying to learn this and i do not understand some of it. I also
tried to searched the web but i couldnt find any answers.
1. I dont understand when i will need to use a function that returns another
function.
eg
def outer():
def inner():
x = 5
return inner
why not just use inner and forget about the whole outer function?
function compositing is one possible use. Functions are first class
objects so they can be passed as arguments to other functions. in math
you can define function composition f(x) * g(x) by saying that (f * g
)(x) = f(g(x)).
so composition of two functions gives you a new function with behaviour
the same as applying fist function to the output of the second.
ex.
you are give two functions f and g to construct their composition:
def outer(f, g):
... def inner(x):
... return f(g(x))
... return inner
...
def f(x):
... print(f ({}) called.format(x))
... return x
...
def g(x):
... print(g ({}) called.format(x))
... return x
...
h = outer(f, g)
h(test)
g (test) called
f (test) called
'test'
2. This is more yes or no question when you pass in a func into another func as
a parameter do you need to specify the parameter that the func is being passed
into as func?
eg
def passinto(func)
pass
def param():
x = 5
p = passinto(param)
also is this above statement correct?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Confused with Functions and decorators
On 19/07/14 11:52, Jerry lu wrote:
Ok so i am trying to learn this and i do not understand some of it. I also
tried to searched the web but i couldnt find any answers.
1. I dont understand when i will need to use a function that returns another
function.
eg
def outer():
def inner():
x = 5
return inner
why not just use inner and forget about the whole outer function?
function compositing is one possible use. Functions are first class
objects so they can be passed as arguments to other functions. in math
you can define function composition f(x) * g(x) by saying that (f * g
)(x) = f(g(x)).
so composition of two functions gives you a new function with behaviour
the same as applying fist function to the output of the second.
ex.
you are give two functions f and g to construct their composition:
def outer(f, g):
... def inner(x):
... return f(g(x))
... return inner
...
def f(x):
... print(f ({}) called.format(x))
... return x
...
def g(x):
... print(g ({}) called.format(x))
... return x
...
h = outer(f, g)
h(test)
g (test) called
f (test) called
'test'
cheers
Wojciech
--
https://mail.python.org/mailman/listinfo/python-list
Re: Confused with Functions and decorators
On 19/07/14 12:40, Jerry lu wrote: oh yeah i forgot about the decorators. Um say that you wanted to decorate a function with the outer() func you would just put @outer on top of it? And this is the same as passing another func into the outer func? yes. syntax was added because with very long function definitions it was dificult to track reassignment to the name when it followed definition of the function. decorators is just abbreviation. def outer(f): ... def inner(*args, **kwargs): ... print(inner function) ... return f(*args, **kwargs) ... return inner ... @outer ... def myfunc(x): ... print(Myfunc, x) ... myfunc(test) inner function Myfunc test it is exactly equivalent to: def outer(f): ... def inner(*args, **kwargs): ... print(inner function) ... return f(*args, **kwargs) ... return inner ... def myfunc(x): ... print(Myfunc, x) ... myfunc = outer(myfunc) myfunc(test) inner function Myfunc test cheers Wojciech and also with the first example you say x is in the scope when is was created can you define x in the outer func and refer to it in the inner func? check nonlocal. -- https://mail.python.org/mailman/listinfo/python-list
Creating Windows Start Menu or Desktop shortcuts using setuptools bdist_winst installer
This is a cross-post from stackoverflow:
http://stackoverflow.com/q/24841130/886669
I am not sure about cross-posting policies of python-list. I am sorry
if this is discouraged.
Here is my problem;
I want to create a start menu or Desktop shortcut for my Python
windows installer package. I am trying to follow
https://docs.python.org/3.4/distutils/builtdist.html#the-postinstallation-script
Here is my script;
import sys
from os.path import dirname, join, expanduser
pyw_executable = sys.executable.replace('python.exe','pythonw.exe')
script_file = join(dirname(pyw_executable), 'Scripts', 'tklsystem-script.py')
w_dir = expanduser(join('~','lsf_files'))
print(sys.argv)
if sys.argv[1] == '-install':
print('Creating Shortcut')
create_shortcut(
target=pyw_executable,
description='A program to work with L-System Equations',
filename='L-System Tool',
arguments=script_file,
workdir=wdir
)
I also specified this script in scripts setup option, as indicated by
aforementioned docs.
Here is the command I use to create my installer;
python setup.py bdist_wininst --install-script tklsystem-post-install.py
After I install my package using created windows installer, I can't
find where my shorcut is created, nor I can confirm whether my script
run or not.
How can I make setuptools generated windows installer to create
desktop or start menu shortcuts?
--
http://ysar.net/
--
https://mail.python.org/mailman/listinfo/python-list
Re: I am stuck on OOP
Am 18.07.2014 20:45, schrieb Chris “Kwpolska” Warrick: Yes, exceptions do exist. But most video tutorials are produced by people without enough knowledge, and people that should not be working on educational material. This is especially visible in videos about basic things: they can be produced by just about anyone with a microphone — which never leads to anything good. (In order to be more precise, I'd have to be politically incorrect.) Moreover people knowing enough about the subject and being able to explain it really well won't necessarily speak clearly. And spoken English is so far away from the written version anyway that it's simply a pain for everybody with another first language. Much worse than learning Python 3 with a version 2 tutorial or vice versa. Greetings Sibylle -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Friday, July 18, 2014 8:21:36 PM UTC-5, Terry Reedy wrote: What ancient version, or oddball system are you using? For me, Win 7, both 2.7.8 and 3.4.1 CONTROL+LEFT_ARROW and the cursor is before the 'a' of [ abc]. The HOME key goes to the same place first, and they before on the second press (and before 'a' on the third). On versions 2.7.2 and 3.2.2 CONTROL+LEFT_ARROW is landing *properly* in front of the prompt, so apparently that bug was fixed since last i checked, my apologies for being ignorant of the situation, but you should understand that i had given up after years of no improvements. However, a *bare* HOME_KEY press is placing the insertion cursor *BEHIND* the prompt of the current line. In a shell environment, you never want to be *BEHIND* the command prompt. Now, in the case of CONTROL+HOME (which places the insertion cursor at the very *first* position of the entire text buffer) and CONTROL+END (which places the insertion cursor at the very *last* position of the text buffer), we should leave the default behaviors alone. I don't see any benefit of changing them. IDLE shell shouldn't use TABs is a high-priority for me. The problem is agreeing on an *exact* specification for new behavior, that takes into account both the limitations and flexibility of tk. Maybe I should start a thread here or python-ideas, where people are willing to discuss details. First, i need to admit that i was wrong when i said: eight space indention, since the IDLE shell is using *tabs* for indention, not spaces! However, a single tab is just as annoying as 8 spaces Now, even as much as i dislike tabs, i must admit there is a benefit to using tabs over spaces, since tabs require only *ONE* backspace key-press per pseudo 4 spaces as compared to spaces which require a 1:1 ratio of key-presses. Of course, even this problem can be abstracted away by backspace automation code, which the IDLE editor window already employs! But my point is: We *MUST* remove this *excessive* indentation width from the IDLE shell! I cannot connect [your complaint about IDLE hanging] to behavior I have seen. IDLE will hang when editing Tkinter code. It seems to happen most often in two cases: 1. When running code that results in a Tkinter error. This can happen when mixing the grid and pack geometry managers within the same container widget, which is a Tkinter NO-NO, but it can also happen during other Tkinter errors! 2. During quickly successive back-to-back run sessions of Tkinter GUI apps. It seems that sometimes, if you don't give IDLE enough time to release resources from the *LAST* run session, it will freeze and then throw a sub-process connection failure message, which, sometimes you can remedy by just trying again, but all to often you are forced to kill the entire IDLE (and related sub-) processes. THIS IS EXTREMELY ANNOYING! However, *EVEN* in the instances where a problem is a direct result of a Tkinter NO-NO (being witting or unwitting), the user of IDLE should *NEVER* be forced to kill processes because: THERE MUST BE A BETTER SOLUTION! And this bug is making the whole Python community look like a bunch of amateurs! I believe there is a proposal to be able to clear the shell window. We just need to add Clear and restart shell. There is also an idea to put help output in an output window. Undo-ing the result of hitting enter seems like a sensible extension of undoing the So sign the contributor agreement and volunteer to write and review patches. I would be willing to help *IF* i received more thoughtful and engaging replies like the type you always provide. Thank you Terry for continuing to be a valuable and welcoming resource for this community! If not for you and a handful of others, i would have given up on this community a long time ago. NOBODY IS GOING TO HELP WHEN THEY GET RESISTANCE! I will visit the bug tracker again and see if i can provide some assistance there. Although, the last time i visited, i remember being annoyed by the tracker interface -- which i feel is overly noisy and far too complicated. All we need is a flat list of issues. Is there some method to export something more readable? Or, some sort of documentation? I must admit, my excitement to help is usually depleted by the tracker interface before i even have a chance to offer anything substantial. If this bug tracker does not improve, i will be forced to continue posting my grievances here. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Sun, Jul 20, 2014 at 2:29 AM, Rick Johnson rantingrickjohn...@gmail.com wrote: On versions 2.7.2 and 3.2.2 CONTROL+LEFT_ARROW is landing *properly* in front of the prompt, so apparently that bug was fixed since last i checked, my apologies for being ignorant of the situation, but you should understand that i had given up after years of no improvements. Standard rule: Before complaining about something, upgrade to the latest version - at least the latest bugfix version of that branch. That would be 2.7.8 and either 3.2.5 or 3.4.1. Complaining about a bug in an old release is quite pointless if that bug has already been fixed. However, a *bare* HOME_KEY press is placing the insertion cursor *BEHIND* the prompt of the current line. In a shell environment, you never want to be *BEHIND* the command prompt. I don't know about the old versions, but in 3.4, it seems to be set so the Home key toggles between the beginning of the code and the beginning of the line. Seems a useful feature, although I can understand if you'd want to disable it and set the Home key to only ever go to the beginning of code. But that's a configuration question; this does not appear to be a bug. But my point is: We *MUST* remove this *excessive* indentation width from the IDLE shell! Why *must*? Is it really that big a problem? THERE MUST BE A BETTER SOLUTION! And this bug is making the whole Python community look like a bunch of amateurs! Frankly, I doubt it. It's pretty obscure. Yes, all bugs should be fixed where possible, but something of the nature you're describing does NOT make Python look bad. (Side point: There's nothing bad about being an amateur. I don't know why so many people think it's an insulting term.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: I am stuck on OOP
On Sat, Jul 19, 2014 at 5:44 PM, Sibylle Koczian nulla.epist...@web.de wrote: Am 18.07.2014 20:45, schrieb Chris “Kwpolska” Warrick: Yes, exceptions do exist. But most video tutorials are produced by people without enough knowledge, and people that should not be working on educational material. This is especially visible in videos about basic things: they can be produced by just about anyone with a microphone — which never leads to anything good. (In order to be more precise, I'd have to be politically incorrect.) Moreover people knowing enough about the subject and being able to explain it really well won't necessarily speak clearly. And spoken English is so far away from the written version anyway that it's simply a pain for everybody with another first language. Depends on the person. I’m perfectly fine with spoken English (as long at it isn’t produced by Asians and other badly-speaking people), and it’s not my mother tongue. -- Chris “Kwpolska” Warrick http://chriswarrick.com/ PGP: 5EAAEA16 stop html mail | always bottom-post | only UTF-8 makes sense -- https://mail.python.org/mailman/listinfo/python-list
Re: I am stuck on OOP
On Sun, Jul 20, 2014 at 2:36 AM, Chris “Kwpolska” Warrick kwpol...@gmail.com wrote: On Sat, Jul 19, 2014 at 5:44 PM, Sibylle Koczian nulla.epist...@web.de wrote: Am 18.07.2014 20:45, schrieb Chris “Kwpolska” Warrick: Yes, exceptions do exist. But most video tutorials are produced by people without enough knowledge, and people that should not be working on educational material. This is especially visible in videos about basic things: they can be produced by just about anyone with a microphone — which never leads to anything good. (In order to be more precise, I'd have to be politically incorrect.) Moreover people knowing enough about the subject and being able to explain it really well won't necessarily speak clearly. And spoken English is so far away from the written version anyway that it's simply a pain for everybody with another first language. Depends on the person. I’m perfectly fine with spoken English (as long at it isn’t produced by Asians and other badly-speaking people), and it’s not my mother tongue. My main issue with spoken (as opposed to written) English is that it becomes so fundamentally linear. You can't skim a podcast and then read in detail the parts you want; it's fiddly to go back and reread something; and it's extremely fiddly to go back and re*write* something, so a lot of errors slip through. (Imagine if you had to type python-list posts without any cursor movement or backspace functionality, but you could go back and retype any one paragraph from scratch. I posit you would leave the odd typo in there, because it's just not worth the effort of fixing it.) Of course, its linearity is a feature for a lot of people, who tend to skim things poorly and not properly learn, but when they're forced to concentrate on what's being fed to them right this second and not worry about the rest, they can comprehend it better; but if you can properly grok a wall of text, that's usually going to be more efficient. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
What's the proper style for a library string function?
Greetings, I typically write a Python 2.7 string function in my library like this: def getCompletedTime(start, end): return Time completed:, str(end - start) And called it like this: print getCompletedTime(start, end) Since every Python script I write is executed from the command line, I rewrote the string function like this: def getCompletedTime(start, end): print Time completed:, str(end - start) And call it like this: getCompletedTime(start, end) The first version is what I'm familiar with having reluctantly learned Java at community college, which couldn't afford a Microsoft site license for Visual C++ and taught every class in Java. (The Linux instructor rebelled against this policy by teaching basic C/C++ and shell scripting in his classes.) I recently read an article that Python is replacing Java as a teaching language. The second version is more straight forward but seems less readable (i.e., print getCompletedTime(start, end) vs. getCompletedTime(start, end)) from the calling script. Alternatively, I thought about rewriting the string function to accept an extra parameter to do either and default to the print statement. def getCompletedTime(start, end, type = 'p'): string = Time completed: + str(end - start) if type == 'p': print string else: return string I'm curious as to what the proper Python style would be for this. Thank you, Chris Reimer -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Sat, Jul 19, 2014 at 10:41 AM, Chris Angelico ros...@gmail.com wrote: However, a *bare* HOME_KEY press is placing the insertion cursor *BEHIND* the prompt of the current line. In a shell environment, you never want to be *BEHIND* the command prompt. I don't know about the old versions, but in 3.4, it seems to be set so the Home key toggles between the beginning of the code and the beginning of the line. Seems a useful feature, although I can understand if you'd want to disable it and set the Home key to only ever go to the beginning of code. But that's a configuration question; this does not appear to be a bug. I'd say that moving the cursor to a position where you can't type is a bug. In that case, beginning of the line should be understood to be after the prompt. I see the use for it in an editing environment (I have an Emacs macro that does the same thing), but I don't really see the point of having the same feature in the shell other than for harmless consistency. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 7/19/2014 12:28 AM, Steven D'Aprano wrote: Earlier, I mentioned a considerable number of IDEs which are available for Python, including: I prefer to use Notepad++ (Windows) and TextWrangler (Mac). Text editors with code highlighting can get the job done as well, especially if the project is modest and doesn't require version control. Chris Reimer -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the proper style for a library string function?
On 19/07/2014 18:38, C.D. Reimer wrote: Greetings, I typically write a Python 2.7 string function in my library like this: def getCompletedTime(start, end): return Time completed:, str(end - start) And called it like this: print getCompletedTime(start, end) Since every Python script I write is executed from the command line, I rewrote the string function like this: def getCompletedTime(start, end): print Time completed:, str(end - start) And call it like this: getCompletedTime(start, end) The first version is what I'm familiar with having reluctantly learned Java at community college, which couldn't afford a Microsoft site license for Visual C++ and taught every class in Java. (The Linux instructor rebelled against this policy by teaching basic C/C++ and shell scripting in his classes.) I recently read an article that Python is replacing Java as a teaching language. The second version is more straight forward but seems less readable (i.e., print getCompletedTime(start, end) vs. getCompletedTime(start, end)) from the calling script. Alternatively, I thought about rewriting the string function to accept an extra parameter to do either and default to the print statement. def getCompletedTime(start, end, type = 'p'): string = Time completed: + str(end - start) if type == 'p': print string else: return string I'm curious as to what the proper Python style would be for this. Thank you, Chris Reimer Besides that I wouldn't write the function on one line, the first. Once you return your data you can do what you want with it. The second you can only write by default to stdout. The third is really horrible in my book, YMMV. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 7/19/2014 3:28 AM, Steven D'Aprano wrote: So why does Python ship with IDLE? On Windows the Idle shell is needed for sensible interactive use. For simply editing a Python file, running it, and fixing it, the Idle editor seems *about* as good as anything. It's not because Python requires an IDE, or that newbies need one, or that there aren't alternatives. The biggest reason for Python shipping with an IDE is not that people are unable to install alternatives, but that a lot of people are *prohibited* from doing so. This is true, but I think it understates the case. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the proper style for a library string function?
On 7/19/2014 11:24 AM, Mark Lawrence wrote: Besides that I wouldn't write the function on one line, the first. I've seen code samples for simple functions with the definition and return statements written on one line. Once you return your data you can do what you want with it. Returning data from a function is probably the part I'm overlooking. The third is really horrible in my book, YMMV. That if/else version was something I've been thinking about doing and didn't it put it together until I wrote my email. If I couldn't write a better version, I wouldn't keep it myself. Chris Reimer -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the proper style for a library string function?
On Sat, Jul 19, 2014 at 12:24 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: Besides that I wouldn't write the function on one line, the first. Once you return your data you can do what you want with it. The second you can only write by default to stdout. The third is really horrible in my book, YMMV. I agree. Optional flags that alter the behavior of functions are considered unpythonic; usually it's better to let the alternative behavior have its own function, particularly if they can share implementation. With that in mind, I would suggest to the OP that you might want to have *two* functions: def format_completed_time(start, end): return Time completed: + str(end - start) def print_completed_time(start, end): print(get_completed_time(start, end)) Also notice that I changed the function naming style from mixedCase to lower_case_with_underscores. This is the style recommended for Python by PEP 8, which you should read if you haven't already. http://legacy.python.org/dev/peps/pep-0008/#naming-conventions I also changed the verb from get to format. get suggests to me that it will retrieve the completed time as a processable value, not as a part of a formatted string. -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the proper style for a library string function?
On Sat, Jul 19, 2014 at 12:52 PM, C.D. Reimer ch...@cdreimer.com wrote: I've seen code samples for simple functions with the definition and return statements written on one line. Personally, I use this style sometimes for easily understood one-line if statements or loops. Named functions consist of an interface declaration and an implementation, and those should be visually separated by a newline. -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the proper style for a library string function?
On 19/07/2014 18:38, C.D. Reimer wrote: Greetings, I typically write a Python 2.7 string function in my library like this: def getCompletedTime(start, end): return Time completed:, str(end - start) Further to my earlier post are you aware of the behaviour of your string function? def getCompletedTime(start, end): return Time completed:, str(end - start) ... t = getCompletedTime(0, -1) type(t) class 'tuple' t[0] 'Time completed:' t[1] '-1' Is this what you intended? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the proper style for a library string function?
On 7/19/2014 11:56 AM, Ian Kelly wrote: On Sat, Jul 19, 2014 at 12:24 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: Also notice that I changed the function naming style from mixedCase to lower_case_with_underscores. This is the style recommended for Python by PEP 8, which you should read if you haven't already. http://legacy.python.org/dev/peps/pep-0008/#naming-conventions I love how that section of PEP 8 begins with: The naming conventions of Python's library are a bit of a mess, so we'll never get this completely consistent -- nevertheless, here are the currently recommended naming standards. My code is certainly in a bit of a mess as I'm still learning Python. Following the Core Python Programming book for the most part, and writing scripts to solve the problems that I'm having. I got an associate degree in computer programming but never mastered a programming language outside of web development. I'll need to unlearn all the bad habits I picked up with PHP over the years. Chris Reimer -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the proper style for a library string function?
On 7/19/2014 12:14 PM, Mark Lawrence wrote: Is this what you intended? I'm in the process of generalizing a library module from my first Python programming project to make it more accessible to other projects. The code I wrote for that project doesn't make sense anymore. As I generalize the library module, I'm also cleaning up the calling code from that project and other scripts. The corrected version of the string function should be: def format_completed_time(start, end): return Time completed: + str(end - start) Chris Reimer -- https://mail.python.org/mailman/listinfo/python-list
Re: What Next After Python Basics
On Sunday, July 13, 2014 10:16:47 PM UTC+2, Orochi wrote: Hi, I am beginner in Python I have Completed Basic Python Course from Codecademy.com . Now that I have a hands on the basics what is the next thing I should do. I mean should I learn more or start a small Project(Any Ideas are Welcomed) or any Other suggestions. Where to Start? Thank You, Orochi I started up going through a few problems on projecteuler.net, and then casually escalated to look through codegolf.stackexchange.com for fun code to study, and even some problem to mimic. So, there's *an* idea. (mind you, might not be the best of ideas). If you're up for it, there's even rosettacode.org, with crazy code which I found fun to study. But mostly, just code. Anything. For my studies, I get assignments to go through large bodies of text and sort them for some criteria, and while I'm given tools to do it, I try to make my own tools to get the job done. That is to say, if there's something in your day that you use in some way, and it's fairly simple, or its essential functionality can be copied, then that's something to copy. I apologize for the raving suggestions. Mathias H. M. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
[A missed point from my last reply...] Terry Reedy said: I believe there is a proposal to be able to clear the shell window. We just need to add Clear and restart shell. A command that allows clearing the *entire* shell display and also resets the global and local symbol tables, *WITHOUT* requiring a re- start of the entire IDLE application, would be a great addition! However, sometimes you just want to remove the displayed result of the *LAST* command executed --for instance, in the case of accidentally printing a *very large* data structure-- and i believe this output undo action should be clearly *DISTINCT* from your normal edit undo actions via: CONTROL+Z To solve this dilemma in *MY* command shell, i use the ALT+UP_ARROW to delete everything from the last command prompt to the end of the text buffer. I think IDLE needs both functionality! There is also an idea to put help output in an output window. I believe more windows just creates more confusion for the user. Sometimes you have no choice but add additional views, however, in this case at least, i believe a menu command (coupled with a keyboard event) is the only solution that can keep the interface manageable. -- https://mail.python.org/mailman/listinfo/python-list
Improving Idle (was Re: Python 3 ...)
On 7/19/2014 12:29 PM, Rick Johnson wrote: On Friday, July 18, 2014 8:21:36 PM UTC-5, Terry Reedy wrote: What ancient version, or oddball system are you using? For me, Win 7, both 2.7.8 and 3.4.1 CONTROL+LEFT_ARROW and the cursor is before the 'a' of [ abc]. The HOME key goes to the same place first, and they before on the second press (and before 'a' on the third). On versions 2.7.2 and 3.2.2 These are ancient versions from years ago that no one should be running Idle on now. Before you say another word about Idle, and I mean this literally, update to current versions. There have been about 80 issues fixed since 2.7.2 and well more than 100 patches pushed. CONTROL+LEFT_ARROW is landing *properly* in front of the prompt, Re-read my comment that you quoted. This has been fixed. But my point is: We *MUST* remove this *excessive* indentation width from the IDLE shell! To repeat: I agree, Raymond Hettigner agrees, everyone seems to agree, and we all have for years. http://bugs.python.org/issue7676 is over 4 years old. But a patch can only implement a specific new behavior, not just 'stop the old'. I cannot connect [your complaint about IDLE hanging] to behavior I have seen. IDLE will hang when editing Tkinter code. It seems to happen most often in two cases: If you are running your tkinter code in the same process with Idle's tkinter code, either with ancient Idle or the '-n' startup option (possibly buried in a script), the situation is hopeless. If you are running your code in a separate process (now the default), then, most likely, Idle is not hanging. It is just waiting for your hung process. If so, Shell / Restart shell (^F6) will end the user process and start a new one. 1. When running code that results in a Tkinter error. This can happen when mixing the grid and pack geometry managers within the same container widget, which is a Tkinter NO-NO, but it can also happen during other Tkinter errors! The user process might hang trying to display a message from *tk*, as oppose to Python code, including tkinter. If you start Idle in a console window with 'python -m idlelib' or in the console interpreter with 'import idlelib.idle', you might see messages from tk, as I sometimes do (especially with a repository debug build). 2. During quickly successive back-to-back run sessions of Tkinter GUI apps. It seems that sometimes, if you don't give IDLE enough time to release resources from the *LAST* run session, it will freeze and then throw a sub-process connection failure message, which, sometimes you can remedy by just trying again, but all to often you are forced to kill the entire IDLE (and related sub-) processes. Use one of the startup options directly above to see if you can get more information. A repeatable or at least semi-repeatable failure case is needed to do anything. However, *EVEN* in the instances where a problem is a direct result of a Tkinter NO-NO (being witting or unwitting), the user of IDLE should *NEVER* be forced to kill processes If you are talking about user processes, and we are talking about patching Idle, as opposed to Python or the OS (such as Windows), I disagree. If you are talking about the Idle process, then yes, I would prefer that once Idle starts, it run forever, and recover from any problems caused by users. Roger Serwy fixed many Idle shutdowns before being swallowed by a PhD program a year ago, but there is more to do. I believe there is a proposal to be able to clear the shell window. We just need to add Clear and restart shell. There is also an idea to put help output in an output window. Undo-ing the result of hitting enter seems like a sensible extension of undoing the So sign the contributor agreement and volunteer to write and review patches. In particular, go to https://www.python.org/psf/contrib to read *about* the contributor agreement and then go to https://www.python.org/psf/contrib-form/ (when the page is working -- it is not at the moment) with Javascript turned on to submit on-line (or submit by old-fashioned s-mail). When the form is processed, the Contributor Form Received field of your user profile at http://bugs.python.org/user12501 will be updated. Also, please update the email on that page to your current one. We are much stricter about getting Contributor Agreements than we used to be. I will usually not look as non-trivial patches until the author has at least signed the agreement and will not commit until it is recorded. I would be willing to help *IF* i received more thoughtful and engaging replies like the type you always provide. On the tracker at least, be polite and ignore impolite posts. I get them occasionally. NOBODY IS GOING TO HELP WHEN THEY GET RESISTANCE! PEP 434 negated some forms of Idle resistance. However, it did not stop resistance in the form of criticism based on how Idle was (or might have
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 20 July 2014 04:08, C.D. Reimer ch...@cdreimer.com wrote: On 7/19/2014 12:28 AM, Steven D'Aprano wrote: Earlier, I mentioned a considerable number of IDEs which are available for Python, including: I prefer to use Notepad++ (Windows) and TextWrangler (Mac). Text editors with code highlighting can get the job done as well, especially if the project is modest and doesn't require version control. IMO there is no project so modest that it doesn't require version control. Especially since version control is as simple as: cd project hg init hg add hg commit FWIW I also don't find a need for an IDE for Python - I'm quite happy using EditPlus (which I preferred enough to other alternatives on Windows to pay for many years ago). Tim Delaney -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the proper style for a library string function?
On 19/07/14 18:38, C.D. Reimer wrote: Greetings, I typically write a Python 2.7 string function in my library like this: def getCompletedTime(start, end): return Time completed:, str(end - start) And called it like this: print getCompletedTime(start, end) Since every Python script I write is executed from the command line, I rewrote the string function like this: def getCompletedTime(start, end): print Time completed:, str(end - start) And call it like this: getCompletedTime(start, end) The first version is what I'm familiar with having reluctantly learned Java at community college, which couldn't afford a Microsoft site license for Visual C++ and taught every class in Java. (The Linux instructor rebelled against this policy by teaching basic C/C++ and shell scripting in his classes.) I recently read an article that Python is replacing Java as a teaching language. The second version is more straight forward but seems less readable (i.e., print getCompletedTime(start, end) vs. getCompletedTime(start, end)) from the calling script. Alternatively, I thought about rewriting the string function to accept an extra parameter to do either and default to the print statement. def getCompletedTime(start, end, type = 'p'): string = Time completed: + str(end - start) if type == 'p': print string else: return string I'm curious as to what the proper Python style would be for this. You might look into PEP8 Style Guide for Python Code it will give you recommendation how to write a code. among other gives most sensible answer: Consistency within a project is more important. Consistency within one module or function is most important.. When in doubt, use your best judgment. Look at other examples and decide what looks best. http://legacy.python.org/dev/peps/pep-0008/#function-names for me if you will be reusing this function I would just use: def getCompletedTime(start, end): return Time completed:, str(end - start) if you need to print just add print, if you want result from this function somewhere else you got it. adding additional arguments necessary adds complexity. do you really need it. Keep it simple stupid expression can be applied everywhere. cheers Wojciech -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
Martin S shieldf...@gmail.com wrote: Is there a point to still use Usenet? Last time I checked noise overwhelmed signal by a factor of something close to 542. news.gmane.org can be a convinient way to read mailing lists instead of getting tons of mail. Sturla -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
c...@isbd.net wrote: That doesn't address the problem at all! :-) You still need a news reader. The problem was that Thunderbird does not support killfiles when used as a newsreader. Leafnode adds filtering capabilities which Thunderbird (supposedly) does not have. Sturla -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
[A missed point from my last reply...] Terry Reedy said: I believe there is a proposal to be able to clear the shell window. We just need to add Clear and restart shell. A command that allows a user to clear the *ENTIRE* shell IO and *ALSO* resets the global and local symbol tables *WITHOUT* requiring a re-start of the IDLE application, would be a great addition indeed! Currently IDLE shell has *ONLY* the Restart Shell command, which simply resets the symbol table whilst leaving all previous shell IO untouched. Which is useful in some situations, but not all... CONSIDER, Sometimes you just want to remove the displayed result of the *LAST* command executed *WHILST* maintaining any previous displayed shell IO -- for instance, in the case of accidentally printing a *very large* data structure, or a horrendously untrimmed dir() requests. #DISAMBIGUATION: EditUndo vs OutputUndo# # In order to prevent confusion with the typical edit-# # undo of CONTROL+Z, we should refer to the action of # # remove the last output displayed as an output-undo. # To solve this dilemma in *MY* command shell, i use the ALT+UP_ARROW to delete everything from the last command prompt up to the end of the text buffer, in effect, creating an output-undo command without *DEFILING* the standard semantics of ubiquitous CONTROL+Z. I think IDLE needs all three functionality of: 1. Reset symbol tables *WHILST* retaining previous shell IO (Already exists via Shell-Restart Shell) 2. Reset symbol tables *AND* clear all shell IO (Maybe: Shell-Reset Shell) 3. Remove the displayed result of the *LAST* command processed. (Maybe: Shell-Remove Last Output) Hotkeys for all three are a must and should be configurable by the user. There is also an idea to put help output in an output window. I believe more windows just creates more confusion for the user. Sometimes you have no choice but to add additional views to a GUI interface, however, in this case at least, i believe a menu command (coupled with a keyboard event) is a best solution to maintain the highest level of interface manageability -- IMHO. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Sun, Jul 20, 2014 at 4:00 AM, Ian Kelly ian.g.ke...@gmail.com wrote: On Sat, Jul 19, 2014 at 10:41 AM, Chris Angelico ros...@gmail.com wrote: However, a *bare* HOME_KEY press is placing the insertion cursor *BEHIND* the prompt of the current line. In a shell environment, you never want to be *BEHIND* the command prompt. I don't know about the old versions, but in 3.4, it seems to be set so the Home key toggles between the beginning of the code and the beginning of the line. Seems a useful feature, although I can understand if you'd want to disable it and set the Home key to only ever go to the beginning of code. But that's a configuration question; this does not appear to be a bug. I'd say that moving the cursor to a position where you can't type is a bug. In that case, beginning of the line should be understood to be after the prompt. You can copy and paste from there. It's functionally equivalent to being able to press Up arrow and move above the currently-editable line. But even if it weren't for that, my statement would still be correct: It's not a bug, and therefore not embarrassment, because it's a feature that you may or may not like. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On Sun, Jul 20, 2014 at 6:39 AM, Rick Johnson rantingrickjohn...@gmail.com wrote: To solve this dilemma in *MY* command shell, i use the ALT+UP_ARROW to delete everything from the last command prompt to the end of the text buffer. I think IDLE needs both functionality! Okay, now I understand Rick's attitude. So long as Idle has one single bug of which he is aware, or lacks one single feature which he can think of, it is an utter and total embarrassment to the entire Python community - not just those who work to make Idle what it is, but also everyone who uses Idle... and everyone who doesn't use Idle, too. Rick, start writing patches, and stop moaning like this just because someone hasn't thought of something you've thought of. It may or may not even be worth implementing this, but definitely you have the wrong attitude toward feature requests. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sun, Jul 20, 2014 at 7:50 AM, Tim Delaney timothy.c.dela...@gmail.com wrote: IMO there is no project so modest that it doesn't require version control. Especially since version control is as simple as: cd project hg init hg add hg commit That said, though, there are some projects so modest they don't require dedicated repositories. I have a repo called shed - it's a collection of random tools that I've put together, no more logical grouping exists. Generally each one is a single file, although I have a couple of related ones in there. (Code at https://github.com/Rosuav/shed if anyone's curious.) If I have an idea for a program that doesn't really merit a full repo, I'll just save it into shed. Keeps the where did I put that, what did I call that to a minimum :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 is killing Python
On 7/19/2014 6:50 PM, Rick Johnson wrote: [A missed point from my last reply...] Terry Reedy said: I believe there is a proposal to be able to clear the shell window. We just need to add Clear and restart shell. # In order to prevent confusion with the typical edit-# # undo of CONTROL+Z, we should refer to the action of # # remove the last output displayed as an output-undo. # That would make implementation easier. I think IDLE needs all three functionality of: 1. Reset symbol tables *WHILST* retaining previous shell IO (Already exists via Shell-Restart Shell) 2. Reset symbol tables *AND* clear all shell IO (Maybe: Shell-Reset Shell) 3. Remove the displayed result of the *LAST* command processed. (Maybe: Shell-Remove Last Output) Hotkeys for all three are a must I consider them a nicety. We will eventually run out of simple hot keys. and should be configurable by the user. I believe anything Idle controls is. There is also an idea to put help output in an output window. In the new issue, I said 'move the last output' from the shell to a window, so it would be entirely optional. I believe more windows just creates more confusion for the user. I expect to eventually look at G.Polo's patch for using tabbed notebooks, which will help with this. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 20 July 2014 09:19, Chris Angelico ros...@gmail.com wrote: On Sun, Jul 20, 2014 at 7:50 AM, Tim Delaney timothy.c.dela...@gmail.com wrote: IMO there is no project so modest that it doesn't require version control. Especially since version control is as simple as: cd project hg init hg add hg commit That said, though, there are some projects so modest they don't require dedicated repositories. I have a repo called shed - it's a collection of random tools that I've put together, no more logical grouping exists. Agreed. I have a utils one - but I do like shed and think I'm going to rename :) The main thing is that versioning should be automatic now - it's almost free, and the benefits are huge because even trivial scripts end up evolving. Tim Delaney -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the proper style for a library string function?
On Sun, Jul 20, 2014 at 4:40 AM, Wojciech Giel wojtekg...@gmail.com wrote: You might look into PEP8 Style Guide for Python Code it will give you recommendation how to write a code. among other gives most sensible answer: Consistency within a project is more important. Consistency within one module or function is most important.. When in doubt, use your best judgment. Look at other examples and decide what looks best. But perhaps the most crucial part of PEP 8 is up in the introductory text: But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. ... Some other good reasons to ignore a particular guideline: 1. When applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP. This is a very New Testament style of guidebook: your conscience is very important, the details of the rules are subordinate to the overriding principle of readability. In Dungeons Dragons terms, you're called to be a paladin with an emphasis on Good where it conflicts with Lawful. This is PEP 8's anti-bureaucracy rule. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
On 19/07/2014 23:38, Sturla Molden wrote: c...@isbd.net wrote: That doesn't address the problem at all! :-) You still need a news reader. The problem was that Thunderbird does not support killfiles when used as a newsreader. Leafnode adds filtering capabilities which Thunderbird (supposedly) does not have. Sturla So what does clicking on Message-Create filter from message... do exactly? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Repo/directory names (was Re: Python and IDEs [was Re: Python 3 is killing Python])
On Sun, Jul 20, 2014 at 10:41 AM, Tim Delaney timothy.c.dela...@gmail.com wrote: On 20 July 2014 09:19, Chris Angelico ros...@gmail.com wrote: That said, though, there are some projects so modest they don't require dedicated repositories. I have a repo called shed - it's a collection of random tools that I've put together, no more logical grouping exists. Agreed. I have a utils one - but I do like shed and think I'm going to rename :) I first met that name on our old DOS and OS/2 systems, set up by my Dad. It was a directory on whichever drive was appropriate (exactly one per installation - we wouldn't risk a network dependency here), and had programs that would probably go in /usr/bin or /usr/local/bin on a Unix system. Part of setting up a new OS/2 installation was always copying E:\SHED (the network drive) to D:\SHED, and putting D:\SHED\NPSWPS\NPSWPS.EXE into Startup. (NPS WPS Enhancer, awesome program. If you have OS/2, get it. What, you don't have OS/2 anywhere? What a surprise.) Other people had, for instance, a C:\BELFRY (best place to have BATs, you know), or other such names. What's your favorite directory/repository name for a concretion of ... random stuff? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 7/19/2014 5:41 PM, Tim Delaney wrote: The main thing is that versioning should be automatic now - it's almost free, and the benefits are huge because even trivial scripts end up evolving. I keep my modest Python scripts in a Dropbox directory and run a weekly Python script to zip up the Dropbox directory for safekeeping on the home file server and Microsoft OneDrive. If I really need a recent copy of a script, Time Machine on the Mac should have a copy from the Drop Box folder. The only time I use version control is when I have a big project with many moving parts and/or I'm publishing software for other people to use. Chris Reimer -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sat, 19 Jul 2014 14:31:10 -0400, Terry Reedy wrote: On 7/19/2014 3:28 AM, Steven D'Aprano wrote: So why does Python ship with IDLE? On Windows the Idle shell is needed for sensible interactive use. One might say that *some* IDE is needed, but Idle itself isn't compulsory :-) It also depends on what you consider sensible. I haven't used Python on Windows much, but when I did use it, I found the standard Python interactive interpreter running under cmd.exe to be bare- bones but usable for testing short snippets. If I recall correctly, it is missing any sort of command history or line editing other than backspace, which I guess it would have been painful to use for extensive interactive work, but when I started using Python on Linux the interactive interpreter had no readline support either so it was just like old times :-) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: What Next After Python Basics
On Sun, Jul 20, 2014 at 6:26 AM, mathias@gmail.com wrote: But mostly, just code. Anything. For my studies, I get assignments to go through large bodies of text and sort them for some criteria, and while I'm given tools to do it, I try to make my own tools to get the job done. That is to say, if there's something in your day that you use in some way, and it's fairly simple, or its essential functionality can be copied, then that's something to copy. I apologize for the raving suggestions. No, that's not raving. The way to get good at something is to do it, and do it a lot. That's why I don't play lasertag, that's why I don't butcher my own meat, that's why I don't write optimizing C compilers. I don't have time to get good at any of those things. (Not that I have a philosophical objection to any. If my circumstances change, I might take one of them up at some point, but for the moment, I don't.) To become a programmer, you need to write programs. As a student programmer, you get very specific tasks: Write a program that, given this input, produces this output; and use exactly these tools (language statements, library functions, etc) to do so. There's a definite right answer and a whole lot of wrong answers. (And it's really obvious when someone asks for help. When the problem's that specific, it's bound to be homework.) As a novice, you generally have fairly specific goals, but now you have flexibility in how you implement it. Import this CSV file into an SQL database, converting 25 Mar 01 into 2001-03-25 as it goes through. You could do that with a preparse script, or you could import into a temporary table and convert it in the database, or you could parse and import in one step. It's fairly straight-forward to figure out whether you've accomplished the goal or made a mess of it, but there's no longer a right way to do it. An expert programmer has to cope with much vaguer requirements. Reduce the number of data entry errors in invoicing. Adding something to a UI that helps people notice errors earlier may not clearly and demonstrably be working, until they've had a chance to get accustomed to it and you start seeing that the error average per week is lower than it was before the feature went in. (And even then, you can't be sure; something else might have caused the improvement.) (An expert will also sometimes get really clear goals. These are good days. These are luxuries. These are the times when you profusely thank the previous programmer for putting in such comprehensive unit tests that the porting process is reduced to make sure all tests pass, then we're done. These are rarities, sadly, but they definitely do exist.) Before you can handle the complex and less-clear jobs, you have to get enough experience to know what you're doing. That means doing jobs that have really clear requirements. Will they be boring? Maybe. Derivative? Almost certainly. But pointless? Absolutely not. And maybe you'll recreate something in almost the same way, but with one little tweak that makes it now absolutely perfect for you. Or recreate something in a different language, just because it's better that way. (I did that myself recently - see http://rosuav.com/1/?id=1009 - even though the old one was working fine.) Never useless, because of what it does for you, the programmer. It takes ten thousand hours of practice to achieve competence. Fortunately, those hours will be enjoyable, if spent programming. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Improving Idle (was Re: Python 3 ...)
On Saturday, July 19, 2014 3:45:07 PM UTC-5, Terry Reedy wrote: On 7/19/2014 12:29 PM, Rick Johnson wrote: [2.7.2 and 3.2.2] are ancient versions from years ago that no one should be running Idle on now. I have just downloaded and installed versions 2.7.8 and 3.4.1, and i am happy to report that both the HOME_KEY *AND* the CONTROL+LEFT_ARROW events are working properly and intuitively. I also would like to give my deepest gratitude and thanks to those who corrected these abnormalities! KEEP UP THE GOOD WORK GUYS! To repeat: I agree [that tab indention is bad], Raymond Hettigner agrees, everyone seems to agree, and we all have for years. http://bugs.python.org/issue7676 is over 4 years old. But a patch can only implement a specific new behavior, not just 'stop the old'. Just checked 3.4.1, and it is still using a tab for indention. I know this issue is going to be a bit more trouble to solve than the previous two event issues that i mentioned, however, i feel it is an important issue to solve. To understand *HOW* we might resolve this issue, *FIRST* we must understand the origins of the issue -- and as such, a few basic rules of how the IDLE shell interacts with a user is prerequisite. 1. The shell presents a prompt (in the case of the IDLE shell the prompt is ), as a starting point for interactive commands. 2. The user begins typing his command at the prompt... 2a. In the process of typing his command, each time the user presses the ENTER or RETURN keys (which i shall from now on refer to them *singularly* as the: ER- KEYS), the shell intuits whether the user intended to complete his command at-the-current-line *OR* that the user intends to continue-writing-more-code, on subsequent lines. Note: As you can see the actions taken by pressing the ER-KEYS depend on the context in which they where pressed! If the command is believed to be *COMPLETE*, then the action will be: evaluate the users command now and display a result, however, if the command is believed to be *INCOMPLETE*, the action will be: allow the user to continue entering his command. 2b. If the shell believes that the user is finished writing his command, the shell will evaluate the *ENTIRETY* of the command (which could span one or more lines!) and then display the result of that evaluation *BENEATH* the command, however, if the shell believes that the user intends to continue-writing-more-code, then the shell will allow the user to continue writing more code. STEP[N:]. There is much more to the interaction between shells and users, however, these first two steps, and their subsequent sub-steps, are all we need to concern ourselves with at this time, in order to solve *THIS* particular problem. Now, between the shell and its user exists a contract, and the preceding steps i outlined describe most of thast contract, however, i realized that i can describe the full contract more clearly by conflating the shell with god and the user as some poor disciple. If we view the contract through the eyes of a *GODLIKE* shell it might read something like: And the shell so-eth declared: Ye shall be presented with a prompt, and from that prompt thou shalt humbly enter requests. When i find thouest requests pleasing, i shall reward thou with my vast knowledge by displaying to you the result utilizing an esthetically pleasing shade of blue, HOWEVER, shall i find thou request to be illogical or malformed, i shall punish thou with furious displays of my rebukes, utilizing the fear color of *BLOOD* red! And thou shalt know my name is the SHELL! Furthermore, ye shall not be allowed to edit previous request, no matter how blasphemous they may be! No, they shall live as a testimate to thouest ignorance, a *PUBLIC* testiment for all to see -- until which time thou decideth to terminate our contract. Now that we understand the contract between shells and users we can focus in on the problem. The problem manifests itself when the user wants to write commands that span *MORE* than one line. For instance, when i write the first line of a multi-line source code like this: for x in range(10): And then i press the enter key, the current IDLE shell is going to insert a tab char (not good!), when it *SHOULD* have inserted a buffer prompt of some kind, and then calculated the correct extrapolation-indentation (by adding four to the indent of line #1, which is four!) for this new line of code. for x in range(10): ... do_something Notice the buffer prompt of ... , after which follows the extrapolation indent of , after which defines the *BEGINNING* of my next command of do_something? Seems simple enough huh? Oh but, my friend, *NOTHING* is simple in this damn community is it! Summary of the attempts to solve INDENTION ISSUE (at
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sun, Jul 20, 2014 at 11:23 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: If I recall correctly, it [Python under cmd.exe] is missing any sort of command history or line editing other than backspace, Not quite, but it has some extreme oddities. I'd have to call them features because I can't imagine them to be bugs, but they're very surprising... like how you can recall something, but if you enter it without any editing, your current recall position is retained. This means you can re-enter a series of lines by recalling the first and then pressing Down, Enter for each subsequent line (it's a feature!), but it means that any usage where the lines are truly independent will start getting very awkward. In contrast, Idle recalls entire suites, rather than individual lines, which (IMO) makes it superior to a readline-based interface. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Improving Idle (was Re: Python 3 ...)
On Sun, Jul 20, 2014 at 11:31 AM, Rick Johnson rantingrickjohn...@gmail.com wrote: Does the IDLE bug-tracker exist to *SOLVE* problems or to *PERPETUATE* them? Definitely the latter. If it weren't for that tracker, bugs would just quietly die on their own. The PSU has a roster for feeding the bugs, changing their litter, and all other bug-related duties, and when someone goes on holidays and forgets to schedule a replacement, heaps of bugs just inexplicably die. (The PSU generally conceals this faux pas under the name of a release.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the proper style for a library string function?
On Sat, 19 Jul 2014 10:38:47 -0700, C.D. Reimer wrote: Greetings, I typically write a Python 2.7 string function in my library like this: def getCompletedTime(start, end): return Time completed:, str(end - start) And called it like this: print getCompletedTime(start, end) Since every Python script I write is executed from the command line, I rewrote the string function like this: def getCompletedTime(start, end): print Time completed:, str(end - start) And call it like this: getCompletedTime(start, end) In general, I much prefer the first version. The general principle I follow is, as much as possible, to separate calculation from display. Advantages include: - You can easily re-use the getCompletedTime function in situations where you don't want to display the time, or pass the result on to another function for further processing before display. - It makes automated testing of the functions much easier. - It makes it easier to vary the type of display. Today you want to print to the standard output. Tomorrow you might want to output to a file, or display in a GUI window. - It makes it easier to understand the large-scale structure of your code. Seeing print getCompletedTime(a, b) makes it pretty clear that you are printing the result of the calculation, whereas getCompletedTime(a, b) does not. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 7/19/2014 6:23 PM, Steven D'Aprano wrote: I haven't used Python on Windows much, but when I did use it, I found the standard Python interactive interpreter running under cmd.exe to be bare- bones but usable for testing short snippets. If I recall correctly, it is missing any sort of command history or line editing other than backspace, which I guess it would have been painful to use for extensive interactive work, but when I started using Python on Linux the interactive interpreter had no readline support either so it was just like old times :-) Windows PowerShell supports very basic Linux commands and has a command history. I'm always typing ls for a directory listing when I'm on a Windows machine. The regular command line would throw a DOS fit. PowerShell lets me get away with it. http://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_of_cmdlets_with_similar_commands I prefer working on my vintage 2006 Black MacBook. Alas, the CPU fan is dying and MacBook shuts down after 15 minutes. I'm surprised at how well I was able to set up a equivalent programming environment on Windows. Chris Reimer -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On Sat, Jul 19, 2014 at 12:28 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: For Python users, the IDEs from Wingware and Activestate are notable: https://wingware.com/ http://komodoide.com/ I would say that since PyCharm (https://www.jetbrains.com/pycharm/) now has a free Community Edition it is an even more notable IDE as the above two programs cost $. And as a Windows user, for version control I really like TortoiseHg ( http://tortoisehg.bitbucket.org/) for Mercurial. Likewise I tend to use TortoiseSVN and TortoiseGit rather than the command line. PyCharm even has support for those but I still like right-clicking on folders in Windows Explorer and activating various hg commands from the popup menu. Especially since not every program I write is written in Python :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Confused with Functions and decorators
ok I seem to very confused about this. Is there like a page or web page that like completely sums this up so i can study. I am going to look up 'functions in python'. I am not sure if this is what we a talking about as a whole here but I'am sure that I'll find something. I am all good with decorators just I can't wrap my head around why we need a function within a function? like the outer and inner thing. for example if we have like: def multi_squared(func): def multi(): return (func)**2 return math @math #does decorator go here or when we call the function??? def number(x, y): return x*y is this above example valid? like this is the stuff i am stuck on like i know what todo or i think i know but not sure if it is perfectly valid. I am going to search for something now but if you know where i could find something like this or if you could sort it out that would be great. -- https://mail.python.org/mailman/listinfo/python-list
Re: Confused with Functions and decorators
On Sun, Jul 20, 2014 at 12:24 PM, Jerry lu nicholascann...@gmail.com wrote: ok I seem to very confused about this. Is there like a page or web page that like completely sums this up so i can study. I am going to look up 'functions in python'. Yep, look up stuff like that. I gave you some keywords to search for (web search - Google, Bing, Yahoo, whatever you're comfortable with) in my last email. They'll start you off with some of the important topics. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Confused with Functions and decorators
Ok thanks so much i really want to get good. I also found this MIT open course lectures for python. Is this good to use as a source of learning? I think it would because it is MIT. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 7/19/2014 7:03 PM, TP wrote: I would say that since PyCharm (https://www.jetbrains.com/pycharm/) now has a free Community Edition it is an even more notable IDE as the above two programs cost $. PyCharm look really nice as an IDE. Thanks for the heads up. Chris Reimer -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
From what I've seen so far it's more like your limited standard mail filtering tool. IIRC when I used Usenet much gnus on Emacs had much more powerful capabilities. /martin s On 20 Jul 2014, Mark Lawrence breamore...@yahoo.co.uk wrote: On 19/07/2014 23:38, Sturla Molden wrote: c...@isbd.net wrote: That doesn't address the problem at all! :-) You still need a news reader. The problem was that Thunderbird does not support killfiles when used as a newsreader. Leafnode adds filtering capabilities which Thunderbird (supposedly) does not have. Sturla So what does clicking on Message-Create filter from message... do exactly? -- Sent with K-@ Mail - the evolution of emailing.-- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
From what I've seen so far it's more like your limited standard mail filtering tool. IIRC when I used Usenet much gnus on Emacs had much more powerful capabilities. /martin s On 20 Jul 2014, Mark Lawrence breamore...@yahoo.co.uk wrote: On 19/07/2014 23:38, Sturla Molden wrote: c...@isbd.net wrote: That doesn't address the problem at all! :-) You still need a news reader. The problem was that Thunderbird does not support killfiles when used as a newsreader. Leafnode adds filtering capabilities which Thunderbird (supposedly) does not have. Sturla So what does clicking on Message-Create filter from message... do exactly? -- Sent with K-@ Mail - the evolution of emailing.-- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
On 2014-07-19, Martin S shieldf...@gmail.com wrote: Is there a point to still use Usenet? Last time I checked noise overwhelm ed signal by a factor of something close to 542. Martin, Fair enough question. Seems like a lot of usenet groups have become spam-fests, and using it to d/l various binaries of questionable origin seems to be the major 'driving force' for a lot of people any more - for pure usenet. As others point out, you can filter the spam fairly easily with a good client program. You don't get (as much of) that kind of spam in forums, depending on the authentication process and the vigilance of the forum staff/moderators. I used to subscribe to a bunch of different Linux and programming-related mailing lists... some of which could run to several hundred messages per month *each*. Yeah, decent filters and storage can mute a lot of that, but not as effeciently as reading the groups via news.gmane.org which provides a mail2news gateway for a lot of mailing lists like this one. I don't have to receive or store all those messages anymore (most of which I skim the subject and then mark as read). That said, the irony that there seems to be a distinct *lack* of GUI usenet reader programs for Linux just kills me. Seems like its either Pan, or knode if you're into KDE. Otherwise... you get to go dredge up old CLI programs like this one (slrn). Works pretty well (better than I remember, actually) but still... having to exit the program and restart it to open a different server is *very* old-school :/ -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
On 2014-07-19, c...@isbd.net c...@isbd.net wrote: memilanuk memila...@gmail.com wrote: Guess where I'm going with this is... is there anything out there worth trying - on Linux - that I'm missing? If slrn was a maybe then there's also tin for text mode news readers, it's what I have always used. I don't know what it does with HTML as none of the groups I frequent ever have any HTML in them. It does add one 'GUIness' to its text mode, it's mouse aware so you can click on messages in a list to open them. slrn does have that option as well... just needs turned on (its off by default) in the config file. I seem to recall it not working so hot... but I tried it on a link in a post last night and it worked like a peach. For whatever reason I never really tried tin (or trn). I might have to give them a whirl... though I must say that using slrn seems kind of like riding a bicycle... my fingers apparently remember more than my brain does ;) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and IDEs [was Re: Python 3 is killing Python]
On 20 July 2014 11:53, C.D. Reimer ch...@cdreimer.com wrote: On 7/19/2014 6:23 PM, Steven D'Aprano wrote: I haven't used Python on Windows much, but when I did use it, I found the standard Python interactive interpreter running under cmd.exe to be bare- bones but usable for testing short snippets. If I recall correctly, it is missing any sort of command history or line editing other than backspace, which I guess it would have been painful to use for extensive interactive work, but when I started using Python on Linux the interactive interpreter had no readline support either so it was just like old times :-) Windows PowerShell supports very basic Linux commands and has a command history. I'm always typing ls for a directory listing when I'm on a Windows machine. The regular command line would throw a DOS fit. PowerShell lets me get away with it. http://en.wikipedia.org/wiki/Windows_PowerShell#Comparison_ of_cmdlets_with_similar_commands I prefer working on my vintage 2006 Black MacBook. Alas, the CPU fan is dying and MacBook shuts down after 15 minutes. I'm surprised at how well I was able to set up a equivalent programming environment on Windows. I advise anyone who works cross-platform to install MSYS on their Windows boxes (for the simplest, most consistent behaviour ignore rxvt and just launch bash -l - i directly). Or use cygwin if you prefer. Tim Delaney -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
On Sun, Jul 20, 2014 at 1:44 PM, Monte Milanuk memila...@invalid.com wrote: That said, the irony that there seems to be a distinct *lack* of GUI usenet reader programs for Linux just kills me. Seems like its either Pan, or knode if you're into KDE. Otherwise... you get to go dredge up old CLI programs like this one (slrn). Works pretty well (better than I remember, actually) but still... having to exit the program and restart it to open a different server is *very* old-school :/ When I wanted to post a question to sci.math, I ended up with Xpn, which seems decent. Got it from the Debian Wheezy repo, so it's convenient to grab. Out of curiosity I just now went back there, found the thread I'd started (no new posts), and skimmed everything that had come in since then. What I'm seeing is: 1) Heaps of threads by one John Gabriel, which have in several cases been followed up with public service announcements saying CRANK ALERT. He seems to be the sci.math equivalent of either Ranting Rick or jmf... but worse than either by a significant margin. Seriously, he makes me happy about how well-off c.l.p is. 2) Other crank threads, boasting of how Newton is right and Einstein wrong, or something. I'm not sure if Archimedes Plutonium is an alias of John Gabriel or not, but I can't be bothered reading the threads to find out. 3) Straight-up spam about adwords, Islam is not a Religion of Extremism (which comes through to c.l.p too, and even crosses the boundary to python-list at times; I see some of that in my Gmail spam box), etc 4) A few homework problems, again similar to what we see here 5) About two threads, and this across roughly two and a half weeks, that are actually interesting and potentially useful. I might be overstating the problem a bit; a sci.math regular might read a bunch of them and find that a few more are useful than the ones that I picked out based on their subject lines. But certainly there is a LOT of spam there. Not as much as there is utter junk that isn't spam (ridiculous crank-posted rubbish outnumbers spam threads by probably 3:1 or more), but still a lot of spam. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: usenet reader software
On Sun, Jul 20, 2014 at 1:48 PM, Monte Milanuk memila...@invalid.com wrote: For whatever reason I never really tried tin (or trn). I might have to give them a whirl... though I must say that using slrn seems kind of like riding a bicycle... my fingers apparently remember more than my brain does ;) Heh, totally. I go back to an old game for some reason, and my fingers know exactly what the Quick Save key is. My brain knows that there are function keys for quick save and quick load in a lot of programs, but is never sure which is which (and it'd be pretty bad to hit the wrong one)... but my fingers always get it right. F1 and F4 for American McGee's Alice, and F9 and F10 for Captain Bible... F6 in CC Renegade (that one's easy, there's no quick load)... Ctrl-X in Angband, although that doesn't quite count... yep, my fingers know them a lot better than my brain does. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Repo/directory names (was Re: Python and IDEs [was Re: Python 3 is killing Python])
Chris Angelico wrote: Other people had, for instance, a C:\BELFRY (best place to have BATs, you know), or other such names. What's your favorite directory/repository name for a concretion of ... random stuff? My project directories typically contain a directory called Attic for putting stuff in that I probably won't use any more, but want to keep just in case. Fortunately, it doesn't have the same space restrictions as its physical namesake. :-) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
[issue19776] Provide expanduser() on Path objects
Claudiu Popa added the comment: No, my home directory is actually /root. The attached patch should be clearer now (I hope). Regarding your question, wouldn't checking for this duplicate what os.path.expanduser already does? (Unless checking for the exact same string before returning it.) -- Added file: http://bugs.python.org/file35994/issue19776_3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19776 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22006] thread module documentation erroneously(?) states not all built-in functions that do blocking I/O release the GIL
Mark Dickinson added the comment: It seems likely that this information is just out of date. But even if there *are* still built-in functions lurking somewhere that don't release the GIL during I/O, the statement in the docs isn't really helpful in finding them. Either way, I'd recommend simply removing it. Adding Guido to the nosy in case he can provide a pre-Python 1.0 historical perspective. -- nosy: +gvanrossum, mark.dickinson versions: -Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22006 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22006] thread module documentation erroneously(?) states not all built-in functions that do blocking I/O release the GIL
Changes by Mark Dickinson dicki...@gmail.com: -- stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22006 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21964] inconsistency in list-generator comprehension with yield(-from)
Changes by Terry J. Reedy tjre...@udel.edu: -- stage: - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21964] inconsistency in list-generator comprehension with yield(-from)
Changes by Terry J. Reedy tjre...@udel.edu: -- versions: -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21997] Pdb.set_trace debugging does not end correctly in IDLE
Xavier de Gaye added the comment: Two issues here: a) in IDLE, on a 'return' debug event in the main module, the step command does not end the debugging session. b) in IDLE, BdbQuit is raised by the quit command when the debugger is started with pdb.set_trace(). I do not know IDLE, but a) seems closely related to issue 14743: on terminating, Pdb debugs itself. As for b) BdbQuit is also raised outside of IDLE (see also issue 16446: pdb raises BdbQuit on 'quit' when started with set_trace): def dodebug(): ... import pdb; pdb.set_trace() ... dodebug() --Return-- stdin(2)dodebug()-None (Pdb) quit Traceback (most recent call last): File stdin, line 1, in module File stdin, line 2, in dodebug File /usr/local/lib/python3.5/bdb.py, line 52, in trace_dispatch return self.dispatch_return(frame, arg) File /usr/local/lib/python3.5/bdb.py, line 96, in dispatch_return if self.quitting: raise BdbQuit bdb.BdbQuit -- nosy: +xdegaye ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21997 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1047397] cgitb failures
Robin Becker added the comment: I'll repeat the post I made to BreamoreBoy regarding this bug: re: http://bugs.python.org/issue1047397 this bug is now 10 years old. I'm not sure why it's to be considered closed because the original intent of the bug report was that the html output of the cgitb module could be confused and errors during evaluation could make the html output fail. So far as I can tell by modifying the original cgitbbug.py to run under python 3.4.1 it still fails to correctly produce html when a bug occurs in cgitb.html. Producing a more reasonable traceback is certainly a step forward, but I think that has been true since at least 3.1. The whole point of cgitb is to produce something reasonable for an html consumer. I have re-created the original 002 patch with mods for python 3.4.1. It's a bit of a shame that this wasn't fixed 10 years ago. Hopefully any style pedants will find this patch more acceptable. Personally I don't think style errors should prevent a working fix from being adopted. I would have just fixed the fix style and carped afterwards. -- Added file: http://bugs.python.org/file35995/bugfix003.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1047397 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22006] thread module documentation erroneously(?) states not all built-in functions that do blocking I/O release the GIL
Antoine Pitrou added the comment: It all depends what you call I/O. What is true is that not all functions doing system calls release the GIL, AFAIR. If you mean I/O as in actual disk or network I/O then yes, all such functions whould release the GIL. That said, I agree that the statement isn't very helpful. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22006 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17528] Implement dumps/loads for lru_cache
Antoine Pitrou added the comment: That doesn't sound like a good idea. lru_cache is a decorator, that acts as transparently as possible (i.e. the decorated function has the same metadata and appearance as the original function). Therefore, the lru_cache'd function should also pickle as a regular function - which it currently does. Having a pickle carry all the cache overhead would actually be a regression - instead of a couple of bytes representing the function's global name, you could now get kilobytes (or more) of data representing the whole cache contents. (and, also, it would fail if the cache contains any non-picklable data) -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17528 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7676] IDLE shell shouldn't use TABs
Stephen Paul Chappell added the comment: If you want the IDLE shell to be as consistent as possible with the editor windows, changing the TAB binding to insert four spaces instead of a tab (alternative 2) would be helpful. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7676 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22011] “make test” fails with 3.4.1 on Ubuntu 12.04
New submission from Yannick Duchêne: `make test` fails with Python 3.4.1 on Ubuntu 12.04 Intel 32 bits. The single `./configure` option used, was `--prefix=$HOME/.local`. As attached file, an archive containing both standard output and standard error outputs. Not some important error notifications appears only in standard output, not in standard error: “OSError: [Errno 28] No space left on device”. The latter is surprising as there was 11GiB free space. -- components: Build files: test-logs.tar.gz messages: 223468 nosy: Hibou57 priority: normal severity: normal status: open title: “make test” fails with 3.4.1 on Ubuntu 12.04 versions: Python 3.4 Added file: http://bugs.python.org/file35996/test-logs.tar.gz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22011 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22007] sys.stdout.write on OS X is not EINTR safe
STINNER Victor added the comment: I can reproduce the issue on Linux: Sorry, I forgot to mention that I reproduced the issue on Fedora 20 with Python 2.7. I cannot reproduce with Python 3.3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22007 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22012] struct.unpack('?', '\x02') returns (False,) on Mac OSX
New submission from Tyler Wade:
On Mac OSX, struct.unpack incorrectly handles bools.
Python 3.4.1 (default, May 19 2014, 13:10:29)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type help, copyright, credits or license for more information.
import struct
struct.unpack('', b'\x00\x01\x02\x03')
(False, True, False, True)
--
assignee: ronaldoussoren
components: Macintosh
messages: 223470
nosy: ronaldoussoren, wayedt
priority: normal
severity: normal
status: open
title: struct.unpack('?', '\x02') returns (False,) on Mac OSX
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22012
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22006] thread module documentation erroneously(?) states not all built-in functions that do blocking I/O release the GIL
Guido van Rossum added the comment: Not in my wildest dreams could I have expected that that claim would still be in the docs 20 years later. :-) Please get rid of it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22006 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22012] struct.unpack('?', '\x02') returns (False,) on Mac OSX
Ned Deily added the comment:
Doing a quick look, the results vary. Using current python.org 2.7.8 and 3.4.1
installers, the results are correct. These interpreters are built with Apple
gcc-4.2 (non-LLVM) from Xcode 3.2.6. Other 2.7 and 3.4.x builds I have
available at the moment, including the Apple-supplied Python 2.7, were built
with clang LLVM and they all give the incorrect result.
$ /usr/bin/python2.7 -c import sys,struct;print(struct.unpack('',
b'\x00\x01\x02\x03'), sys.version)
((False, True, False, True), '2.7.5 (default, Mar 9 2014, 22:15:05) \n[GCC
4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)]')
$ arch -i386 /usr/bin/python2.7 -c import
sys,struct;print(struct.unpack('', b'\x00\x01\x02\x03'), sys.version)
((False, True, False, True), '2.7.5 (default, Mar 9 2014, 22:15:05) \n[GCC
4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)]')
$ /usr/local/bin/python2.7 -c import sys,struct;print(struct.unpack('',
b'\x00\x01\x02\x03'), sys.version)
((False, True, True, True), '2.7.8 (v2.7.8:ee879c0ffa11, Jun 29 2014, 21:07:35)
\n[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]')
$ /usr/local/bin/python2.7-32 -c import sys,struct;print(struct.unpack('',
b'\x00\x01\x02\x03'), sys.version)
((False, True, True, True), '2.7.8 (v2.7.8:ee879c0ffa11, Jun 29 2014, 21:07:35)
\n[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]')
$ /usr/local/bin/python3.4 -c import sys,struct;print(struct.unpack('',
b'\x00\x01\x02\x03'), sys.version)
(False, True, True, True) 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 00:54:21)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
$ /usr/local/bin/python3.4-32 -c import sys,struct;print(struct.unpack('',
b'\x00\x01\x02\x03'), sys.version)
(False, True, True, True) 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 00:54:21)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
$ ./bin/python3.4 -c import sys,struct;print(struct.unpack('',
b'\x00\x01\x02\x03'), sys.version)
(False, True, False, True) 3.4.1+ (3.4:d6b71971b228, Jul 16 2014, 16:30:56)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)]
--
nosy: +ned.deily
versions: -Python 3.1, Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22012
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21907] Update Windows build batch scripts
Mark Lawrence added the comment: Does this render the patch against build_pgo.bat on #17667 obsolete? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21907 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17667] Windows: build with build_pgo.bat -2 fails to optimize python.dll
Mark Lawrence added the comment: See also #21907. -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17667 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17709] http://docs.python.org/2.7/objects.inv doesn't support :func:`repr` or :exc:`Exception`
Mark Lawrence added the comment: I don't understand this at all, but if this is a Sphinx bug shouldn't it be reported on the appropriate bug tracker and not here? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17709 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17667] Windows: build with build_pgo.bat -2 fails to optimize python.dll
Changes by Brian Curtin br...@python.org: -- nosy: -brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17667 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22006] thread module documentation erroneously(?) states not all built-in functions that do blocking I/O release the GIL
Roundup Robot added the comment: New changeset 4f359c631bb0 by Mark Dickinson in branch '2.7': Issue #22006: Remove outdated thread module caveat. Thanks Dan O'Reilly for the report. http://hg.python.org/cpython/rev/4f359c631bb0 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22006 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22006] thread module documentation erroneously(?) states not all built-in functions that do blocking I/O release the GIL
Roundup Robot added the comment: New changeset 855ff9182a07 by Mark Dickinson in branch '3.4': Issue #22006: Remove outdated _thread caveat. Thanks Dan O'Reilly for the report. http://hg.python.org/cpython/rev/855ff9182a07 New changeset 3b6b905ae229 by Mark Dickinson in branch 'default': Issue #22006: Merge from 3.4. http://hg.python.org/cpython/rev/3b6b905ae229 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22006 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
