Re: Python handles globals badly.
Op 05-09-15 om 02:05 schreef Vladimir Ignatov: >> To me, marking a variable as global in a large number of functions is >> a code smell that indicates that you're probably overusing globals. >> Lua is an example of a language that takes the opposite approach: in >> Lua, every variable is global unless you explicitly mark it as local. >> Lua is a fine language overall, but that is one of my pet peeves with > I had some experience programming in Lua and I'd say - that language > is bad example to follow. > Indexes start with 1 (I am not kidding) What is so bad about that? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Op 04-09-15 om 02:47 schreef Mark Lawrence: > On 04/09/2015 01:06, Michael Torrie wrote: >> On 09/03/2015 01:05 PM, t...@freenet.de wrote: >> >>> [The same e.g. with switch statement: add it] >> >> Switch is a nice-to-have thing, but definitely not essential. A PEP here >> (probably already has been several) would at least be read anyway. >> However, there are several idiomatic ways of accomplishing the same >> thing that are often good enough and familiar to any Python programmer >> out there. Since functions are first-class objects, often a dispatch >> table is the best way to go here. >> > > https://www.python.org/dev/peps/pep-3103/ "A Switch/Case Statement" by > Guido van Rossum, "Rejection Notice - A quick poll during my keynote > presentation at PyCon 2007 shows this proposal has no popular support. > I therefore reject it". > > https://www.python.org/dev/peps/pep-0275/ "Switching on Multiple > Values" by Marc-André Lemburg, "Rejection Notice - A similar PEP for > Python 3000, PEP 3103 [2], was already rejected, so this proposal has > no chance of being accepted either." > Were those polls, like the poll he once did for the condtional expression? There the poll indicated no specific proposal had a majority, so for each specific proposal one could say it didn't have popular support, but the majority still prefered to have a conditional expression. But at that time Guido used that poll as an indication there was not enough support. So colour me a bit sceptical when Guido comes with such a poll. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Op 04-09-15 om 04:33 schreef Steven D'Aprano: > On Fri, 4 Sep 2015 05:05 am, t...@freenet.de wrote: > >> Would you remove this keyword if it would be technically possible > Absolutely not. > > I do not believe that it is technically possible, but even if it were, I > would still argue that the Zen of Python applies: > > Explicit is better than implicit. > > Local variables should be the default, and you should explicitly declare any > time you want to write to a global. > > Not the other way around, like Lua does. I've always thought that was silly: > you should make the *desirable* thing easy to do, and the *dangerous* think > (using globals) possible but not easy to do by accident. You are trying to have your cake and eat it. If explicit is better than implicit then declaring your variable at the scope it has to live in, is what you need to do, that is the explicit way. Not needing to declare local variables, is an implicit way, since it is behaviour depending on something not being indicated. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 08/09/2015 09:59, Antoon Pardon wrote: Op 04-09-15 om 02:47 schreef Mark Lawrence: On 04/09/2015 01:06, Michael Torrie wrote: On 09/03/2015 01:05 PM, t...@freenet.de wrote: [The same e.g. with switch statement: add it] Switch is a nice-to-have thing, but definitely not essential. A PEP here (probably already has been several) would at least be read anyway. However, there are several idiomatic ways of accomplishing the same thing that are often good enough and familiar to any Python programmer out there. Since functions are first-class objects, often a dispatch table is the best way to go here. https://www.python.org/dev/peps/pep-3103/ "A Switch/Case Statement" by Guido van Rossum, "Rejection Notice - A quick poll during my keynote presentation at PyCon 2007 shows this proposal has no popular support. I therefore reject it". https://www.python.org/dev/peps/pep-0275/ "Switching on Multiple Values" by Marc-André Lemburg, "Rejection Notice - A similar PEP for Python 3000, PEP 3103 [2], was already rejected, so this proposal has no chance of being accepted either." Were those polls, like the poll he once did for the condtional expression? Polls, there is only one referred to above? There the poll indicated no specific proposal had a majority, so for each specific proposal one could say it didn't have popular support, but the majority still prefered to have a conditional expression. But at that time Guido used that poll as an indication there was not enough support. So colour me a bit sceptical when Guido comes with such a poll. In that case there were either two different polls, or one of us is mistaken, as I was very much under the impression that as there was no clear winner for a conditional expression, but a majority wanted one, Guido simply picked the one he favoured. Hum, IIRC that was backed up by an analysis of the standard library. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: python---configure file
In a message of Tue, 08 Sep 2015 10:00:26 +0800, "chenc...@inhand.com.cn" write
s:
>
>hi:
>I download the python2.7.10 package and execute cmd: ./configure
>--help.It is messages as follow:
>
>Optional Packages:
>--with-PACKAGE[=ARG]use PACKAGE [ARG=yes]
>--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
> --with-universal-archs=ARCH
> select architectures for universal build
>("32-bit",
> "64-bit", "3-way", "intel" or "all")
> --with-framework-name=FRAMEWORK
> specify an alternate name of the framework built
> with --enable-framework
> ..
> ..
>--with(out)-ensurepip=[=OPTION]
> "install" or "upgrade" using bundled pip,
>default is "no"
> So, I do not know how to use package option: --with-PACKAGE[=ARG].
>It(PACKAGE) means 3rd party packages which I download from website?
>which directory can i put it In python2.7.10 package? For example, I
>download pip7.1.2 from website and I put it in python2.7.10 package dir.
>Therefor, I add compile option --with-pip7.1.2=yes when i compile
>python2.7.10. Does it correct? --with(out)-ensurepip=[=OPTION], how can
>i use it?Is there anybody know that?
>
The only times I have used with-PACKAGE if you want to
configure a python package, and it wants to use a package or
a stand-alone executable, and you want to override the choice
it would naturally make in finding one of these other packages
it wants to use. the PACKAGE whose name you replace isn't the
one you are trying to configure, but another one.
i.e.
You are setting up mod_wsgi
you type ./configure
mod_wsgi wants to configure apache, and looks for an executable file
called apxs (or apxs2) which you should have installed wherever your
distro puts such things, so for me it is /usr/bin/apxs.
I don't want to use this one. I want to use my own special one,
or an older version of apache, or something.
I type:
./configure --with-apxs /the/full/path/name/of/the/apxs/I/want/to/use
So that is what the --with-PACKAGE is for. I do not think it is something
that is related to your problem at all, but I am not an expert at this.
The distutils-sig
https://mail.python.org/mailman/listinfo/distutils-sig
(with the letter 't') is where you find the experts.
Laura
--
https://mail.python.org/mailman/listinfo/python-list
pygame basic question
Hi
DISPLAYSURF = pygame.display.set_mode((400, 300))
pygame.display.set_caption('Hello World!')
The first line opens a 400x300 pygame window.
The second one writes "Hello World" on top of it.
I am just wondering how function set_caption finds the windows
since the window's name DISPLAYSURF is not passed as
an argument
It would have understood something like:
DISPLAYSURF.set_caption('Hello World!')
or
pygame.display.set_caption(DISPLAYSURF, 'Hello World!')
thx
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Op 08-09-15 om 11:22 schreef Mark Lawrence: > On 08/09/2015 09:59, Antoon Pardon wrote: > >> There the poll indicated no specific proposal had a majority, so for >> each >> specific proposal one could say it didn't have popular support, but the >> majority still prefered to have a conditional expression. But at that >> time Guido used that poll as an indication there was not enough support. >> >> So colour me a bit sceptical when Guido comes with such a poll. >> > > In that case there were either two different polls, or one of us is > mistaken, as I was very much under theimpression that as there was no > clear winner for a conditional expression, but a majority wanted one, > Guido simply picked the one he favoured. Hum, IIRC that was backed up > by an analysis of the standard library. > You are mistaken. Guido originally used the fact that there was no clear winner to reject the proposal for a conditional expression. And each time someone would ask for one on this list they would be referred to the "and or" construction that was proposed as an alternative. But then some time later one of the core developers was bitten by an elusive bug (in the standard library I think) because the and-or construction didn't work as expected when the middle expression evaluated to something equivallent to false. It was then that Guido decided to have a conditional expression and chose the one he favoured. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
In a message of Tue, 08 Sep 2015 10:59:01 +0200, Antoon Pardon writes: >Were those polls, like the poll he once did for the condtional expression? >There the poll indicated no specific proposal had a majority, so for each >specific proposal one could say it didn't have popular support, but the >majority still prefered to have a conditional expression. But at that >time Guido used that poll as an indication there was not enough support. > >So colour me a bit sceptical when Guido comes with such a poll. That's not how I remember it: There were people who wanted, a conditional expression, 'preferably , but if I cannot have that, any of the other syntaxes'. These were the people who were very passionate about wantinhg a conditional expression. There were other people who wanted a conditional expression, _but only with my preferred syntax_. Given a choice between another syntax and not having it, they would prefer to not have one. A good number of these people were more in the 'I wouldn't mind ...' than passionate wanters of a conditional expression. I was in the third group. Passionately not wanting any conditional expression whatsoever. Group 2 was the largest group. Thus while 1 plus 2 outnumbered 3, for each proposed syntax 3 plus 'the members of group 2 who didn't want this syntax' outnumbered 1 plus 'the members of group 2 who did'. Thus a mess, heavily complicated by a very interesting discussion about what sort of voting method would be appropriate to make such a choice, and non-winner-take-all systems in general. Laura -- https://mail.python.org/mailman/listinfo/python-list
Re: pygame basic question
Try the pygame mailing list for that one. http://www.pygame.org/wiki/info?action=view&id=4890 Laura -- https://mail.python.org/mailman/listinfo/python-list
Python CI and CD support available on Semaphore (feedback appreciated)
HI folks, We have recently launched Python support on our continuous integration and deployment service and are looking for communities feedback. If you're up for it, please give a test drive to our service with your Python projects and give us your thoughts on what we could further improve upon. Official blog post announcing Python support: http://bit.ly/1KYrVsT Our website: https://semaphoreci.com/ Thanks in advance! BTW we offer free plans for open source projects and have limited free plans for private projects. -- https://mail.python.org/mailman/listinfo/python-list
Re: pygame basic question
On 08/09/2015 11:14, Laura Creighton wrote: Try the pygame mailing list for that one. http://www.pygame.org/wiki/info?action=view&id=4890 Laura Or https://www.reddit.com/r/pygame -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
passing double quotes in subprocess
I need to execute an external shell script via subprocess on Linux. One of the parameters needs to be passed inside double quotes But the double quotes do not appear to be passed to the script I am using : myscript = '/home/john/myscript' commandline = myscript + ' ' + '\"Hello\"' process = subprocess.Popen(commandline, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) output,err = process.communicate() if I make the call from another shell script and escape the double quotes it works fine, but not when I use python and subprocess. I have googled this but cannot find a solution...is there one? -- https://mail.python.org/mailman/listinfo/python-list
Re: passing double quotes in subprocess
On Tue, Sep 8, 2015 at 7:03 AM, loial wrote: > I need to execute an external shell script via subprocess on Linux. > > One of the parameters needs to be passed inside double quotes > > But the double quotes do not appear to be passed to the script > > I am using : > > myscript = '/home/john/myscript' > commandline = myscript + ' ' + '\"Hello\"' > > process = subprocess.Popen(commandline, shell=True, stdout=subprocess.PIPE, > stderr=subprocess.PIPE) > output,err = process.communicate() > > > if I make the call from another shell script and escape the double quotes it > works fine, but not when I use python and subprocess. > > I have googled this but cannot find a solution...is there one? Try it with 2 backslashes: commandline = myscript + ' ' + '\\"Hello\\"' -- https://mail.python.org/mailman/listinfo/python-list
Re: passing double quotes in subprocess
On Tue, Sep 8, 2015 at 9:03 PM, loial wrote:
> I need to execute an external shell script via subprocess on Linux.
>
> One of the parameters needs to be passed inside double quotes
>
> But the double quotes do not appear to be passed to the script
>
> I am using :
>
> myscript = '/home/john/myscript'
> commandline = myscript + ' ' + '\"Hello\"'
>
> process = subprocess.Popen(commandline, shell=True, stdout=subprocess.PIPE,
> stderr=subprocess.PIPE)
> output,err = process.communicate()
>
>
> if I make the call from another shell script and escape the double quotes it
> works fine, but not when I use python and subprocess.
>
> I have googled this but cannot find a solution...is there one?
First off: Can you remove the shell=True and provide the command as a
list, so it doesn't need to be parsed? If you can, that would be MUCH
better.
But if you can't, the simple fix is to use a raw string literal for
your Hello. The backslashes are getting lost:
>>> print('\"Hello\"')
"Hello"
>>> print(r'\"Hello\"')
\"Hello\"
If In Doubt, Print It Out. It's amazing how much you can learn with a
few well-placed print() calls :)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: passing double quotes in subprocess
Yep, that did the trick...cheers On Tuesday, September 8, 2015 at 12:04:05 PM UTC+1, loial wrote: > I need to execute an external shell script via subprocess on Linux. > > One of the parameters needs to be passed inside double quotes > > But the double quotes do not appear to be passed to the script > > I am using : > > myscript = '/home/john/myscript' > commandline = myscript + ' ' + '\"Hello\"' > > process = subprocess.Popen(commandline, shell=True, stdout=subprocess.PIPE, > stderr=subprocess.PIPE) > output,err = process.communicate() > > > if I make the call from another shell script and escape the double quotes it > works fine, but not when I use python and subprocess. > > I have googled this but cannot find a solution...is there one? -- https://mail.python.org/mailman/listinfo/python-list
Re: passing double quotes in subprocess
loial writes:
> I need to execute an external shell script via subprocess on Linux.
>
> One of the parameters needs to be passed inside double quotes
>
> But the double quotes do not appear to be passed to the script
>
> I am using :
>
> myscript = '/home/john/myscript'
> commandline = myscript + ' ' + '\"Hello\"'
>
> process = subprocess.Popen(commandline, shell=True, stdout=subprocess.PIPE,
> stderr=subprocess.PIPE)
> output,err = process.communicate()
>
>
> if I make the call from another shell script and escape the double
> quotes it works fine, but not when I use python and subprocess.
>
> I have googled this but cannot find a solution...is there one?
You don't need shell=True here:
#!/usr/bin/env python3
from subprocess import Popen, PIPE
cmd = ['/home/john/myscript', 'Hello'] # if myscript don't need quotes
# cmd = ['/home/john/myscript', '"Hello"'] # if myscript does need quotes
with Popen(cmd, stdout=PIPE, stderr=PIPE) as process:
output, errors = process.communicate()
In general, to preserve backslashes, use raw-string literals:
>>> print('\"')
"
>>> print(r'\"')
\"
>>> print('\\"')
\"
>>> '\"' == '"'
True
>>> r'\"' == '\\"'
True
--
https://mail.python.org/mailman/listinfo/python-list
Re: Permission denied error in download nltk_data...
import nltk
nltk.download('maxent_treebank_pos_tagger¹)
Is now giving the error:
[nltk_data] Error loading maxent_treebank_pos_tagger:
Any suggestions, please.
BIG SMILE...
Always, Dwight
--
https://mail.python.org/mailman/listinfo/python-list
Re: Wheels For ...
On 06.09.2015 22:06, Ned Batchelder wrote: As a developer of a Python package, I don't see how this would be better. The developer would still have to get their software into some kind of uniform configuration, so the central authority could package it. You've moved the problem from, "everyone has to make wheels" to "everyone has to make a tree that's structured properly." But if we can do the second thing, the first thing is really easy. Unfortunately, I disagree with you one that and others already gave explanations why. Internally, we had this "wild-west" tree in our source as well but we moved on to a properly structured tree and it solved problems we didn't even imagine to have solved when starting this effort some years ago. Best, Sven -- https://mail.python.org/mailman/listinfo/python-list
issue while doing pexpect ssh
Some where i am missing simple logic :)
=
child = pexpect.spawn('ssh hari@hostname')
child.logfile = sys.stdout
child.expect('hari\'s Password: ')
=
getting error as follows:
child.expect('hari\'s Password: ')
TypeError: must be str, not bytes
===
Thanks...
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
>> I had some experience programming in Lua and I'd say - that language >> is bad example to follow. >> Indexes start with 1 (I am not kidding) > > What is so bad about that? It's different from the rest 99.9% of languages for no particular reason. ( => perfect example of "design smell" => not a good example to follow) Vladimir http://itunes.apple.com/us/app/python-code-samples/id1025613117 -- https://mail.python.org/mailman/listinfo/python-list
Re: Permission denied error in download nltk_data...
In a message of Tue, 08 Sep 2015 18:56:15 +0800, Dwight GoldWinde writes:
>import nltk
>nltk.download('maxent_treebank_pos_tagger¹)
>
>Is now giving the error:
>
>[nltk_data] Error loading maxent_treebank_pos_tagger: [nltk_data] [Errno 57] Socket is not connected>
>
>
>Any suggestions, please.
>
>
>
>
>--
>https://mail.python.org/mailman/listinfo/python-list
>
I think you had better ask this question over here:
https://groups.google.com/forum/#!forum/nltk-users
Give the people more context in the error message -- don't trim
it so much. They will want the full traceback, with line numbers
and all the rest.
Laura
--
https://mail.python.org/mailman/listinfo/python-list
Re: issue while doing pexpect ssh
In a message of Tue, 08 Sep 2015 04:37:09 -0700, harirammanohar...@gmail.com wr
ites:
>Some where i am missing simple logic :)
>
>=
>child = pexpect.spawn('ssh hari@hostname')
>child.logfile = sys.stdout
>child.expect('hari\'s Password: ')
>=
>
>getting error as follows:
>
>child.expect('hari\'s Password: ')
>TypeError: must be str, not bytes
>===
>
>Thanks...
>--
>https://mail.python.org/mailman/listinfo/python-list
https://pexpect.readthedocs.org/en/latest/api/pexpect.html#run-function
you want to use spawnu because you have a unicode string.
Laura
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Vladimir Ignatov writes: >>> I had some experience programming in Lua and I'd say - that language >>> is bad example to follow. >>> Indexes start with 1 (I am not kidding) >> >> What is so bad about that? > > It's different from the rest 99.9% of languages for no particular reason. > > ( => perfect example of "design smell" => not a good example to follow) > It is not just a matter of tradition. Even if you were to invent the very first programming language; there are reasons to prefer the zero-based indexing. See "Why numbering should start at zero" https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 08-09-2015 12:55, Vladimir Ignatov wrote: I had some experience programming in Lua and I'd say - that language is bad example to follow. Indexes start with 1 (I am not kidding) What is so bad about that? It's different from the rest 99.9% of languages for no particular reason. ( => perfect example of "design smell" => not a good example to follow) Assuming that some programming language makes design choices "for no apparent reason" is your first hint you should probably reevaluate your position. People who design programming languages don't tend to throw coins to the air. Lua was based of a scientific language with a strong mathematical core, where 1-index arrays make more sense and are standard. The authors didn't expect for the language to become successful and by the time it did, you couldn't just change anymore such a core aspect of your language. 1-index arrays tend to be a problem in Lua, only for those people that don't normally program in Lua. Those that do, quickly learn to use them and they are not more difficult or easy to use than 0-index arrays. There is nothing inherently bad about 1-index arrays. They are just different, with some of the disadvantages being balanced by some of its advantages. And there either no design smell here. From the perspective of the language user (the programmer), the choice of the starting index of an array should have no impact on their ability to code. It's just another semantic aspect of the language they should learn. No different than having to learn other semantic nuances of each particular language. In fact, a great language is the one that offers the ability for the user to decide what starting index they want to use. Depending on the data structure a user sometimes is better served by a 0-index array, others by a 1-index array, and if you are doing an array with the letters of the alphabet you would love to have an array starting at 'a'. -- https://mail.python.org/mailman/listinfo/python-list
Re: issue while doing pexpect ssh
On Tue, Sep 8, 2015 at 9:37 PM, wrote:
> Some where i am missing simple logic :)
>
> =
> child = pexpect.spawn('ssh hari@hostname')
> child.logfile = sys.stdout
> child.expect('hari\'s Password: ')
> =
>
> getting error as follows:
>
> child.expect('hari\'s Password: ')
> TypeError: must be str, not bytes
> ===
Laura's already answered your actual question. But I would recommend
using public key login rather than keying in a password; it's a lot
more secure, as it means you don't have to embed a password in your
source code (or at very best, on your hard disk in some other readable
and decryptable way). It also simplifies the transaction
significantly.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: pygame basic question
"ast" wrote:
>DISPLAYSURF = pygame.display.set_mode((400, 300))
>pygame.display.set_caption('Hello World!')
>
>The first line opens a 400x300 pygame window.
>The second one writes "Hello World" on top of it.
>
>I am just wondering how function set_caption finds the windows
>since the window's name DISPLAYSURF is not passed as
>an argument
https://www.pygame.org/docs/ref/display.html
As it says, there is only *one* display surface, and any non-displayed
surface must be blitted (copied) onto the display surface for
visibility. So all "pygame.display" methods refer to that one display
surface. Non displayed surfaces, on the other hand, do need to be
instantiated with "pygame.Surface"
--
https://mail.python.org/mailman/listinfo/python-list
Re: pygame basic question
On Tue, Sep 8, 2015 at 8:01 AM, Dave Farrance wrote:
> "ast" wrote:
>
>>DISPLAYSURF = pygame.display.set_mode((400, 300))
>>pygame.display.set_caption('Hello World!')
>>
>>The first line opens a 400x300 pygame window.
>>The second one writes "Hello World" on top of it.
>>
>>I am just wondering how function set_caption finds the windows
>>since the window's name DISPLAYSURF is not passed as
>>an argument
>
> https://www.pygame.org/docs/ref/display.html
>
> As it says, there is only *one* display surface, and any non-displayed
> surface must be blitted (copied) onto the display surface for
> visibility. So all "pygame.display" methods refer to that one display
> surface. Non displayed surfaces, on the other hand, do need to be
> instantiated with "pygame.Surface"
Also, note that the display surface DISPLAYSURF is not the window.
It's just a Surface object that pygame uses to paint the contents of
the window. AFAIK pygame maintains the actual window data structures
internally and does not expose them to the API.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Tue, Sep 8, 2015 at 5:55 AM, Vladimir Ignatov wrote: >>> I had some experience programming in Lua and I'd say - that language >>> is bad example to follow. >>> Indexes start with 1 (I am not kidding) >> >> What is so bad about that? > > It's different from the rest 99.9% of languages for no particular reason. It's not "different from the rest 99.9% of languages". There are many languages that use 1-based indexing, e.g. Matlab, Pascal, Fortran. None of those are even the worst offender here, IMO. That honor goes to Visual Basic 6, where the default lower bound is 0, but the programmer has the option of declaring an array to use any lower bound they want, or even globally change the default. As a result you have to look up the array declaration to know the lower bound, and even then you can't be sure if it's not explicit. The correct way to iterate over a loop in VB 6 is thus not "FOR i = 0 TO n-1", but "FOR i = LBound(arr) TO UBound(arr)" which is overly verbose and means that you can't even be sure what indexes you're actually iterating over inside the loop. I believe this wart is fixed in VB .NET. -- https://mail.python.org/mailman/listinfo/python-list
Re: [RELEASED] Python 3.5.0rc3 is now available
On 08/09/2015 02:35, Larry Hastings wrote: > > > On behalf of the Python development community and the Python 3.5 release > team, I'm relieved to announce the availability of Python 3.5.0rc3, also > known as Python 3.5.0 Release Candidate 3. > > The next release of Python 3.5 will be Python 3.5.0 final. There should > be few (or no) changes to Python 3.5 between rc3 and final. > > This is a preview release, and its use is not recommended for production > settings. > > > You can find Python 3.5.0rc3 here: > > https://www.python.org/downloads/release/python-350rc3/ > > Windows and Mac users: please read the important platform-specific > "Notes on this release" section near the end of that page. > > > Happy hacking, I notice that one new feature that isn't mentioned in the 'what's new' list is the addition of math.gcd() offering a faster and more generic implementation (in that it returns a positive result) of the greatest common divisor operation. Thanks for this and for all your work on Python 3.5. -- https://mail.python.org/mailman/listinfo/python-list
Re: issue while doing pexpect ssh
On 09/08/2015 03:57 PM, Chris Angelico wrote:
On Tue, Sep 8, 2015 at 9:37 PM, wrote:
Some where i am missing simple logic :)
=
child = pexpect.spawn('ssh hari@hostname')
child.logfile = sys.stdout
child.expect('hari\'s Password: ')
=
getting error as follows:
child.expect('hari\'s Password: ')
TypeError: must be str, not bytes
===
Laura's already answered your actual question. But I would recommend
using public key login [snip]
ChrisA
My 2 cents, beside the public key, use the python module paramiko,
unless you really want to work at the low level yourself.
http://docs.paramiko.org/en/1.15/api/client.html
JM
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Wed, 9 Sep 2015 12:31 am, Ian Kelly wrote: > On Tue, Sep 8, 2015 at 5:55 AM, Vladimir Ignatov > wrote: I had some experience programming in Lua and I'd say - that language is bad example to follow. Indexes start with 1 (I am not kidding) >>> >>> What is so bad about that? >> >> It's different from the rest 99.9% of languages for no particular reason. > > It's not "different from the rest 99.9% of languages". There are many > languages that use 1-based indexing, e.g. Matlab, Pascal, Fortran. Correct. Nearly all natural languages start counting at 1, not 0, as do quite a few programming languages, such as PL/I, Algol60 and others. You'll note that languages that are designed for mathematics (Matlab, Mathematica, Julia) tend to use 1-based indexes. This is not an accident. Guido discusses why he choose 0-based indexing like in C, instead of 1-based indexing like in ABC: http://python-history.blogspot.com.au/2013/10/why-python-uses-0-based-indexing.html He links to this fantastic discussion of why C ended up with 0-based indexing: http://exple.tive.org/blarg/2013/10/22/citation-needed/ It's a wonderful read. See also: http://c2.com/cgi/wiki?WhyNumberingShouldStartAtOne http://c2.com/cgi/wiki?WhyNumberingShouldStartAtZero Anyone who thinks that there is one right answer here simply isn't paying attention. > None of those are even the worst offender here, IMO. That honor goes > to Visual Basic 6, where the default lower bound is 0, but the > programmer has the option of declaring an array to use any lower bound > they want, or even globally change the default. I'll just point out that some algorithms are best written with 0-based arrays, and some are best with 1-based arrays. I shouldn't have to change languages to change from one to the other! -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Tue, Sep 8, 2015, at 10:31, Ian Kelly wrote:
> I believe this wart is fixed in VB .NET.
This is apparently true, but the weird thing is it was done late enough
in the design cycle that the .NET runtime still has features meant to
support it. You can create such an array with the Array.CreateInstance
method. For multidimensional arrays, you can even assign them to a
variable of the proper type (You can't do that for single-dimension
arrays since a single-dimension array with a nonzero lower bound is a
different type than a normal array). And the LBound and UBound methods
in the Microsoft.VisualBasic.Information class still support it.
The feature is so obscure that even the compiler doesn't do well with it
- if you create (via MSIL) a strongly-typed method that returns such an
array, the compiler will think it returns a normal array.
Of course, on the subject of warts, Dim x(5) as Integer or Dim x as
Integer() = new Integer(5){} still creates an array with size 6 (upper
bound is 5). You're free to use indices 0..4 or 1..5 if you want, but
0..5 are valid.
--
https://mail.python.org/mailman/listinfo/python-list
Re: issue while doing pexpect ssh
In a message of Tue, 08 Sep 2015 23:57:41 +1000, Chris Angelico writes:
>On Tue, Sep 8, 2015 at 9:37 PM, wrote:
>> Some where i am missing simple logic :)
>>
>> =
>> child = pexpect.spawn('ssh hari@hostname')
>> child.logfile = sys.stdout
>> child.expect('hari\'s Password: ')
>> =
>>
>> getting error as follows:
>>
>> child.expect('hari\'s Password: ')
>> TypeError: must be str, not bytes
>> ===
>
>Laura's already answered your actual question. But I would recommend
>using public key login rather than keying in a password; it's a lot
>more secure, as it means you don't have to embed a password in your
>source code (or at very best, on your hard disk in some other readable
>and decryptable way). It also simplifies the transaction
>significantly.
>
>ChrisA
This poor soul cannot login at all. He needs this hack to let him
su some-other-user because of a draconian policy he cannot do
anything about. If he could just log in, one heck of a lot of
other things would be simpler for him ...
Laura
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 2015-09-08 15:31, Ian Kelly wrote: On Tue, Sep 8, 2015 at 5:55 AM, Vladimir Ignatov wrote: I had some experience programming in Lua and I'd say - that language is bad example to follow. Indexes start with 1 (I am not kidding) What is so bad about that? It's different from the rest 99.9% of languages for no particular reason. It's not "different from the rest 99.9% of languages". There are many languages that use 1-based indexing, e.g. Matlab, Pascal, Fortran. In Pascal you specify both the lower and the upper bounds. None of those are even the worst offender here, IMO. That honor goes to Visual Basic 6, where the default lower bound is 0, but the programmer has the option of declaring an array to use any lower bound they want, or even globally change the default. As a result you have to look up the array declaration to know the lower bound, and even then you can't be sure if it's not explicit. The correct way to iterate over a loop in VB 6 is thus not "FOR i = 0 TO n-1", but "FOR i = LBound(arr) TO UBound(arr)" which is overly verbose and means that you can't even be sure what indexes you're actually iterating over inside the loop. I believe this wart is fixed in VB .NET. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Before reflecting latest answers
a short absolute last statement about that matter:
Differ: globals (traditional, sharing vars app wide, NOT meant)
globals (module vars outside functions, meant here at least when I
mention this term)
global (the keyword used inside functions)
I did not say - make no comparions or no OO-wording. Sure, write what you have
to write
but hopefully especially as long as it changes not the topic of
this thread.
I did say - lay OO and sharing globals down (which again appears
and is NOT the topic (at least not mine)).
Point.
Reflecting latest answers, but not the new topic ("Progam in or into")
which has arrived , I want add following:
"""
Some statements brought into discussion (myself), read or skip down the closing
"
-- Comparison with Javscript:
Saying that Javascript and LUA does it samewise seems not correct
from reading the thread.
LUA is said it has it vice versa: local instead of a global
But Javascript does have neither local nor global keyword so far I know,
but has also a local scope (block scope).
The other Python-proposals aside "global":
-- switch statement:
PEP3103, it is PEP from Guido van Rossum!
I can only say: If even a "good and senseful" PEP from Guido is denied from
community I do better not comment.
-- indentation:
I am not sure if the sample has been changed from posting
but the line "count +=1" is clearly integrated
at the outer loop (at least in my browser)
(even process(line) is in that post in the outer loop)
No, I meant simply
count = 0
for file in files:
for line in open(file): # tab indent
process(line) # 2 space indent
count += 1
so, e.g. the first indent has 1 tab to the right, the second 2 spaces to the
right.
Why I am not free about this? Context is clear for me.
(I want not say I do this with intent, but if it happens: Ok, shit happens,
I need no script-error if it happens. Really not)
-- Universal scope
Yes proably ok.
you mean what builtins? Or What builtins suits best?
-- goto
I would say ok.
For the times you need such a construct it should be enough.
-- include statement
Not sure if we meant the same:
With including I meant the virtual merge of two or more scripts
(once merged it is executed as one script with one namespace:
a module var X in script A is directly available in script B,C,...)
Different is that including with namespaces is something special.
And if you search around the web there are different pseudo-includes proposals
(Side-effects unknown!?)
And with scopes, namespaces and every aspects to careof (memory, efficient file
reading,
compiled sources, caches) are something what should be provided from Python
itself
and should not be a construct from the developer.
According the Python philospophy ("one best way").
"""
Now back to the main topic:
-- "global"-keyword
Main point from my side is further (compared e.g. with Javascript)
Python needs the keyword "global" to give write access to a global(=module-var).
Only for that reason I would NOT need a "global" keyword
Though accepted that there are dynamic constructions which needs maybe a global
or even (but still not really believe) technical (compiler) reasons to have it
maybe,
but when rethinking it, escpecially about the dynamics constructs,
I still not really understand this reasons?:
At the risk of going in a circle:
Globals are of module-scope only.
I think it is NOT possible to have same var names xxx as global and
local(function-var)
and use them in parallel. Even with the sample provided:
exec("""def function():
global {0}
{0} = 42
""".format('x'))
For me this says that only: {0} is writeable. Nothing more,
No distinction needed if local or global.
Or is there an example out there where I really have to
distinct a same var name - inside a single module I would not know?
And even with more modules, than the distinction is done by namespace prefix.
I see no other value in the keyword "global" except the write-protection.
Proof:
Each sample provided would work without global (or you get runtime failure
while try to write a global).
So the compiler knows the distiction between global and local already.
Otherwise you would have to write in every function this keyword
But this is not the case. You write it because you need write access.
And this is an over-regulation. So, I say: NO need for an explicit global.
Optional ok.
Conclusion (for me):
So for me the reasons about dynamic constructions or compiler thinks
aren'that revelant as described.
"global" is provided only to help the developer not to overwrite a global by
mistake,
and should be removeable if this protection is not wanted (by the community),
at least optional.
And this (and even the other points) would not change Python,
or is a matter of "Use Python language correct" or "try not to write Java".
Sure
Re: Python handles globals badly.
On Tue, Sep 8, 2015 at 11:53 AM, wrote: > -- Comparison with Javscript: > Saying that Javascript and LUA does it samewise seems not correct > from reading the thread. > LUA is said it has it vice versa: local instead of a global > But Javascript does have neither local nor global keyword so far I know, > but has also a local scope (block scope). In Javascript the keyword is "var", not "local", but it amounts to the same thing: this variable is local, and if you don't use it then your variable is not local. > so, e.g. the first indent has 1 tab to the right, the second 2 spaces to the > right. > Why I am not free about this? Context is clear for me. It's clear for you in your particular editor configuration. In somebody else's editor who has tabs configured differently, it may appear completely different. The compiler has no way of knowing what your editor's tab settings are, so it considers the indentation ambiguous. > I would rather say, this would enhance the power and flexibility of the > Python language even further. > Especially from the scripting point of view (without harm Python hardliner) > And by the way, I still believe that these changes would let Python overrun > Javascript and PHP. > There would practically no more any reasons for Javascript+NodeJS and > especially PHP. > I even think, a huge wave of developers would change then to Python. > Including webhosters which I think did not know or want not know anything > about Python 3.x. I think that you greatly exaggerate the impact of these changes, which are all quite cosmetic in nature. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Wed, Sep 9, 2015 at 4:09 AM, Ian Kelly wrote: >> I would rather say, this would enhance the power and flexibility of the >> Python language even further. >> Especially from the scripting point of view (without harm Python hardliner) >> And by the way, I still believe that these changes would let Python overrun >> Javascript and PHP. >> There would practically no more any reasons for Javascript+NodeJS and >> especially PHP. >> I even think, a huge wave of developers would change then to Python. >> Including webhosters which I think did not know or want not know anything >> about Python 3.x. > > I think that you greatly exaggerate the impact of these changes, which > are all quite cosmetic in nature. EVERYONE who suggests massive, sweeping changes says "hey, if you only make these changes, Python will actually become popular". It's almost mandatory. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Silly question about pip
On 8-9-2015 17:54, wxjmfa...@gmail.com wrote: > win7 / py433 > > How to downgrade from the latest pip (7.1.2) to > the previous one? > I'm sorry, I do not remember the numerous msgs > I saw when updating. (Yesterday) > > (I'm serious) > > Now, what? > I think: $ pip install --upgrade pip==7.0.0 would do the trick, where you substitute the required version number for 7.0.0. Irmen -- https://mail.python.org/mailman/listinfo/python-list
Re: Python CI and CD support available on Semaphore (feedback appreciated)
On 9/8/2015 6:27 AM, Filip Komnenović wrote: We have recently launched Python support on our continuous integration and deployment service and are looking for communities feedback. If you're up for it, please give a test drive to our service with your Python projects and give us your thoughts on what we could further improve upon. Have you considered integrating with bitbucket as well as github? Official blog post announcing Python support: http://bit.ly/1KYrVsT Our website: https://semaphoreci.com/ BTW we offer free plans for open source projects and have limited free plans for private projects. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
PIP does not appear to handle diacritics correctly.
Dear group, I do use Windows 7 and have a user name with diacritics. Whenever I am querying an extension with pip, it will fail since it does not pass on the user folder correctly. I thought PIP deals well with unicode, doesn't it? Has anyone a clue how to fix it? Thank you -- Stand up against TTIP and ISDS ! -- https://mail.python.org/mailman/listinfo/python-list
RE: Python CI and CD support available on Semaphore (feedback appreciated)
> To: python-list@python.org > From: tjre...@udel.edu > Subject: Re: Python CI and CD support available on Semaphore (feedback > appreciated) > Date: Tue, 8 Sep 2015 14:46:28 -0400 > > On 9/8/2015 6:27 AM, Filip Komnenović wrote: > > > We have recently launched Python support on our continuous integration and > > deployment service and are looking for communities feedback. If you're up > > for it, please give a test drive to our service with your Python projects > > and give us your thoughts on what we could further improve upon. > > Have you considered integrating with bitbucket as well as github? Bitbucket is supported, not just Github (like most CIs). The information is kinda hidden (or at least not as clearly visible as the Github integration): https://semaphoreci.com/docs/adding-github-bitbucket-project-to-semaphore.html I see Ubuntu 14.04 LTS 64-bit VMs are used. I would love to be able to run my tests on Linux, Mac OS and Windows in one go. > > > Official blog post announcing Python support: http://bit.ly/1KYrVsT > > Our website: https://semaphoreci.com/ > > > BTW we offer free plans for open source projects and have limited free > > plans for private projects. > > -- > Terry Jan Reedy > > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Need Help w. PIP!
On Sat, Sep 5, 2015 at 3:14 AM, Thomas 'PointedEars' Lahn < pointede...@web.de> wrote: > > Cody Piersall wrote: > > > Please respond to the list as well as the person you're actually talking > > to. It works out better for everyone that way. (You should just have to > > "reply all" instead of "reply"). > > “Better” as in “getting/reading/downloading the same message *twice*”? > > The rule of thumb is: write here, read here. Some people email the list, but aren't subscribed to it. So I guess a better rule is to just reply-to-all for the OP? Cody -- https://mail.python.org/mailman/listinfo/python-list
Re: PIP does not appear to handle diacritics correctly.
On 08/09/2015 20:14, Laszlo Lebrun via Python-list wrote: Dear group, I do use Windows 7 and have a user name with diacritics. Whenever I am querying an extension with pip, it will fail since it does not pass on the user folder correctly. I thought PIP deals well with unicode, doesn't it? Has anyone a clue how to fix it? Thank you Can you please cut and paste exactly what you tried and the failure messages, as there's a lot of smart people around here but we're not mind readers :) Which Python and pip version are you using? Did you install pip yourself or did it come with your Python installation? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 08/09/2015 18:41, MRAB wrote: On 2015-09-08 15:31, Ian Kelly wrote: On Tue, Sep 8, 2015 at 5:55 AM, Vladimir Ignatov wrote: I had some experience programming in Lua and I'd say - that language is bad example to follow. Indexes start with 1 (I am not kidding) What is so bad about that? It's different from the rest 99.9% of languages for no particular reason. It's not "different from the rest 99.9% of languages". There are many languages that use 1-based indexing, e.g. Matlab, Pascal, Fortran. In Pascal you specify both the lower and the upper bounds. I vaguely recall that in CORAL66/250 you specified both bounds and the lower bound could be negative. Do other languages allow this or does the lower bound always have to be positive? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 2015-09-08 23:41, Mark Lawrence wrote: On 08/09/2015 18:41, MRAB wrote: On 2015-09-08 15:31, Ian Kelly wrote: On Tue, Sep 8, 2015 at 5:55 AM, Vladimir Ignatov wrote: I had some experience programming in Lua and I'd say - that language is bad example to follow. Indexes start with 1 (I am not kidding) What is so bad about that? It's different from the rest 99.9% of languages for no particular reason. It's not "different from the rest 99.9% of languages". There are many languages that use 1-based indexing, e.g. Matlab, Pascal, Fortran. In Pascal you specify both the lower and the upper bounds. I vaguely recall that in CORAL66/250 you specified both bounds and the lower bound could be negative. Do other languages allow this or does the lower bound always have to be positive? If you're allowed to specify both bounds, why would you be forbidden from negative ones? A better question would be whether there's a language that allows you to specify a lower bound, but insists that it's non-negative. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 09/09/2015 00:20, MRAB wrote: On 2015-09-08 23:41, Mark Lawrence wrote: On 08/09/2015 18:41, MRAB wrote: On 2015-09-08 15:31, Ian Kelly wrote: On Tue, Sep 8, 2015 at 5:55 AM, Vladimir Ignatov wrote: I had some experience programming in Lua and I'd say - that language is bad example to follow. Indexes start with 1 (I am not kidding) What is so bad about that? It's different from the rest 99.9% of languages for no particular reason. It's not "different from the rest 99.9% of languages". There are many languages that use 1-based indexing, e.g. Matlab, Pascal, Fortran. In Pascal you specify both the lower and the upper bounds. I vaguely recall that in CORAL66/250 you specified both bounds and the lower bound could be negative. Do other languages allow this or does the lower bound always have to be positive? If you're allowed to specify both bounds, why would you be forbidden from negative ones? I haven't the faintest idea :) A better question would be whether there's a language that allows you to specify a lower bound, but insists that it's non-negative. Ditto :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 09/08/2015 09:56 AM, Steven D'Aprano wrote: > http://exple.tive.org/blarg/2013/10/22/citation-needed/ > > It's a wonderful read. I read this article, but I'm still uncertain to what his point actually is. It's a great review of the history of C, some batch computing, and IBM's CEO's penchant for boat racing. He tries to say that 0-based indexing made for faster compiling, but given the runtime nature of BCPL's ! operator, I don't see how it wouldn't affect runtime also. He also says that saying pointers are the reason for 0-based indexing then you're wrong, except that BCPL's creator says in this same article that array variables are essentially pointers. A few people tried to point this out in the comments but the author simply lambasted them, saying thinks like, "Thanks for leaving a comment. I'm sure it's made you feel clever." Like I say I guess I must have missed his point in there somewhere. I suppose his point is C is 0-based because BCPL was, and I'm sure that's true, but I'm also sure K&R saw some benefits to keeping this in C. In any case, 0-based indexing in Python makes a lot of sense when you bring in the slicing syntax. Especially if you think of slicing as operating on the boundaries between cells as it were. I used a 1-based indexed language (BASIC) for many years, and I was always having to subtract 1 from things. So 0-based is simply more convenient for me. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
MRAB writes: > If you're allowed to specify both bounds, why would you be forbidden > from negative ones? It makes it non-obvious what value should be returned from e.g. search methods that return a negative number on failure. .NET's IndexOf function returns -1, but MaxValue if the array has a negative bound. BinarySearch returns the complement of the nearest index to the value you were searching for, which requires some gymnastics if you want to make use of it for an array that has negative and positive bounds. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 09-09-2015 01:25, Vladimir Ignatov wrote: It's different from the rest 99.9% of languages for no particular reason. ( => perfect example of "design smell" => not a good example to follow) Assuming that some programming language makes design choices "for no apparent reason" is your first hint you should probably reevaluate your position. People who design programming languages don't tend to throw coins to the air. Okay, I reevaluated my position and suddenly found that 1-based indexes is such a honking great idea! Now I have another difficulty though. How to justify absence of built-in unicode support in a language carefully designed in 1993 ? Sarcasm noted. Because: a) In 1993, ANSI C (C89) of which Lua had been developed had poor multibyte and wide character support. It was only with C95 that this stabilized. b) It didn't needed Unicode support for what it was initially designed for; a scripting language to provide programming capabilities to data-descriptive and configuration languages. c) As the years moved Lua eventually implemented support for the storage of unicode strings, but doesn't provide any higher level functions (including character traversing or searching). This is so because by that time, that task had already fallen to the unicode libraries that had been developed in the meantime. Note: You know, it is a pointless exercise to try and downplay programming languages (any programming language) that has proven its worth by being generally adopted by the programming community. Adoption is the sign of a respected and well designed language. You are just wasting your time. Even if you can find here and there some apparent flaw of arguable design choice, that will be true of any programming language. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Mario Figueiredo writes: > Note: > You know, it is a pointless exercise to try and downplay programming > languages (any programming language) that has proven its worth by > being generally adopted by the programming community. Adoption is the > sign of a respected and well designed language. I can think of numerous widely-adpoted languages that disprove that assertion, by nevertheless being poorly-designed languages that are loathed by the vast majority of programmers who use them. On the other hand, I think there is merit in an argument that runs the other way: the quality of languages that a community adopts are predictive of the quality of programs that community will produce. -- \ “It's up to the masses to distribute [music] however they want | `\… The laws don't matter at that point. People sharing music in | _o__)their bedrooms is the new radio.” —Neil Young, 2008-05-06 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Wed, Sep 9, 2015 at 11:26 AM, Ben Finney wrote: > On the other hand, I think there is merit in an argument that runs the > other way: the quality of languages that a community adopts are > predictive of the quality of programs that community will produce. Broadly, yes. But regardless of its flaws, a language can be used because of a unique position; for instance, JavaScript/ECMAScript is going to continue to be the primary language of client-side web browser scripting for a long time, unless the major browsers all start supporting a new language (and until they all do, the benefit to one of them is low). ECMAScript isn't an abysmal language by any means, but it certainly has detectable flaws that come up fairly consistently. (Easy example: Find any fill-out form that says "Maximum X characters" and has a little counter that ticks down as you type. Now key in some astral characters. The odds are fairly good that they'll decrement the counter by 2 each.) If Apple declares that the iPhone 9 will be programmed exclusively in Even Swiftier, then it won't matter how terrible a language it is, people who want to say "Our app works on the iPhone 9" will write it in Even Swiftier. That's how PHP got to its position of being the default web scripting language for so many people - if you got yourself some cheap hosting, you could confidently expect PHP support, but until relatively recently, you couldn't depend on Ruby or Python (and certainly couldn't install your own); which, in turn, means that anyone who's building something for other people to deploy (a wiki, a forum, a blogging system, etc) will write it in PHP. And in all of these cases, a competent programmer can turn out good quality code. But if you take the average of all PHP programs, it'll tend toward a level that much better follows your estimate. A poorer language will generally have an overall poorer codebase. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On 09-09-2015 02:26, Ben Finney wrote: Mario Figueiredo writes: Note: You know, it is a pointless exercise to try and downplay programming languages (any programming language) that has proven its worth by being generally adopted by the programming community. Adoption is the sign of a respected and well designed language. I can think of numerous widely-adpoted languages that disprove that assertion, by nevertheless being poorly-designed languages that are loathed by the vast majority of programmers who use them. On the other hand, I think there is merit in an argument that runs the other way: the quality of languages that a community adopts are predictive of the quality of programs that community will produce. I'll have to agree to an extent. And you did remind me of PHP. So there's that. But in a way PHP served an important purpose in its time. Despite its flaws, it was once an important language that helped solve programming problems. And for that it served the purpose. Many of us went through it for the lack of a better fast-and-dirty alternative to server-side scripting. I remember others, like Cold Fusion or ASP. (Can't recall exactly why Cold Fusion didn't experience a wider support. But, truth be told I barely touched it). In any case, it stands that, unless a programming language is so ruined by bad design choices it is unusable, there is some kind of merit to its ability to solve computational problems. And Lua, Java, Python, C++, C, let me stop naming some popular or mildly popular languages, aren't nowhere close to being in that game. They are superior choices, despite our personal dislikes. I can't stand Java. I just don't think calling it a mistake. It's worth has been proven by its level of adoption and by the usable software that has been made with it. Javascript/ECMAScript is criticized by so many and yet there's no denying of its importance. Even today we struggle to find a better alternative to client-side scripting. Python is criticized by so many. And yet I don't think calling on Python developers as an inferior breed of programmers. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Wed, Sep 9, 2015 at 12:43 PM, Mario Figueiredo wrote: > I can't stand Java. I just don't think calling it a mistake. It's worth has > been proven by its level of adoption and by the usable software that has > been made with it. Javascript/ECMAScript is criticized by so many and yet > there's no denying of its importance. Even today we struggle to find a > better alternative to client-side scripting. Yeah, the reason for that is simple: anything else adds (sometimes massive) overhead. Would you suggest creating a client/server architecture, a RESTful API, and a triple-redundant HTTPS+SSL+Blowfish security system, to enumerate files on your hard drive? No, you'd just use ls(1). In the same way, there's not a lot of point downloading megs and megs of PyPyJS engine before running a single line of code, when you could skip that and just write in JS. Before Python can be "a better alternative", it has to overcome this massive hump. If Python 3.x were as well supported by web browsers as ECMAScript 5.x is, I think we'd see a dramatic shift in usage. But it ain't, so we won't. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Wed, 9 Sep 2015 09:55 am, Michael Torrie wrote: > On 09/08/2015 09:56 AM, Steven D'Aprano wrote: >> http://exple.tive.org/blarg/2013/10/22/citation-needed/ >> >> It's a wonderful read. > > I read this article, but I'm still uncertain to what his point actually > is. It's a great review of the history of C, some batch computing, and > IBM's CEO's penchant for boat racing. He tries to say that 0-based > indexing made for faster compiling, but given the runtime nature of > BCPL's ! operator, I don't see how it wouldn't affect runtime also. He > also says that saying pointers are the reason for 0-based indexing then > you're wrong, except that BCPL's creator says in this same article that > array variables are essentially pointers. You know about the boat races, so you obviously read the article... so how did you miss the part where the author explicitly raises the exact objection you do? [quote] “Now just a second, Hoye”, I can hear you muttering. “I’ve looked at the BCPL manual and read Dr. Richards’ explanation and you’re not fooling anyone. That looks a lot like the efficient-pointer-arithmetic argument you were frothing about, except with exclamation points.” And you’d be very close to right. That’s exactly what it is – the distinction is where those efficiencies take place, and why. [end quote] > A few people tried to point > this out in the comments but the author simply lambasted them, saying > thinks like, "Thanks for leaving a comment. I'm sure it's made you feel > clever." If people raise an objection that is already raised and covered in the text, I'd be a tad snarky too. Like the guy who objects, tells the author he ought to read Dijkstra, and *utterly failed* to notice that the article links to the same paper. Or the guy who somehow decided that the length of a 1-based array wasn't end-start, but "there’s always a +1 or -1 to be strewn in there". O rly? 0-based indexes: [0|1|2|3|4], end-start = 4-0 = 4 1-based indexes: [1|2|3|4|5], end-start = 5-1 = 4 And yes, the fellow Joe who completely missed the point of the blog post, and made the comment "You don’t think you’re wrong and that’s part of a much larger problem, but you’re still wrong" completely deserved to be called out on his lack of reading comprehension and smugness. > Like I say I guess I must have missed his point in there > somewhere. I suppose his point is C is 0-based because BCPL was, and > I'm sure that's true, but I'm also sure K&R saw some benefits to keeping > this in C. The post has *nothing* to do with why languages today might use 0-based arrays. It's not a post about which is better, or an attack on 0-based languages. It's about the historical forces that lead to design decisions being made, and how computer science is almost completely blind to those forces. Lacking real insight into why decisions are made, the IT field is dominated by superstitious post-hoc rationales being given as "the reason" why things are the way they are, when the truth is far more interesting. > In any case, 0-based indexing in Python makes a lot of sense when you > bring in the slicing syntax. Especially if you think of slicing as > operating on the boundaries between cells as it were. > > I used a 1-based indexed language (BASIC) for many years, and I was > always having to subtract 1 from things. So 0-based is simply more > convenient for me. There are certainly advantages to 0-based indexing. But there are also advantages to 1-based. For example, many mathematical algorithms are best written in terms of 1-based indexes, or at least are described as such. For example, quartile calculations. I'm constantly having to adjust such algorithms to work with Python. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Tue, 8 Sep 2015 06:59 pm, Antoon Pardon wrote: > Op 04-09-15 om 02:47 schreef Mark Lawrence: >> On 04/09/2015 01:06, Michael Torrie wrote: >>> On 09/03/2015 01:05 PM, t...@freenet.de wrote: >>> [The same e.g. with switch statement: add it] >>> >>> Switch is a nice-to-have thing, but definitely not essential. A PEP here >>> (probably already has been several) would at least be read anyway. >>> However, there are several idiomatic ways of accomplishing the same >>> thing that are often good enough and familiar to any Python programmer >>> out there. Since functions are first-class objects, often a dispatch >>> table is the best way to go here. >>> >> >> https://www.python.org/dev/peps/pep-3103/ "A Switch/Case Statement" by >> Guido van Rossum, "Rejection Notice - A quick poll during my keynote >> presentation at PyCon 2007 shows this proposal has no popular support. >> I therefore reject it". >> >> https://www.python.org/dev/peps/pep-0275/ "Switching on Multiple >> Values" by Marc-André Lemburg, "Rejection Notice - A similar PEP for >> Python 3000, PEP 3103 [2], was already rejected, so this proposal has >> no chance of being accepted either." >> > Were those polls, like the poll he once did for the condtional expression? > There the poll indicated no specific proposal had a majority, so for each > specific proposal one could say it didn't have popular support, but the > majority still prefered to have a conditional expression. But at that > time Guido used that poll as an indication there was not enough support. In the case of conditional expression, there is *no good alternative*. Using if...then statement is too heavyweight, and cannot be used in an expression. Using "flag and true_value or false_value" is buggy -- it fails if true_value is itself false. Refactoring it to a function uses eager rather than lazy evaluation. So there was no existing alternative to a ternary if expression that worked correctly. In the case of case/switch, there is no consensus on what the statement should do, how it should work, what purpose it has, or what syntax it should use. Rather than "there's no alternative to a case statement", the situation was more like "there are many good alternatives to the various different case statements people want". -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Tue, Sep 8, 2015 at 9:27 PM, Steven D'Aprano wrote: > Using if...then statement is too heavyweight, and cannot be used in an > expression. Using "flag and true_value or false_value" is buggy -- it fails > if true_value is itself false. Refactoring it to a function uses eager > rather than lazy evaluation. So there was no existing alternative to a > ternary if expression that worked correctly. I used to see "(flag and [true_value] or [false_value])[0]" fairly often, which solves the bugginess problem by ensuring that the second term can't be false. Not that I would recommend it over an actual conditional expression. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
Mario Figueiredo writes: > On 09-09-2015 02:26, Ben Finney wrote: > > Mario Figueiredo writes: > > > >> You know, it is a pointless exercise to try and downplay > >> programming languages (any programming language) that has proven > >> its worth by being generally adopted by the programming community. > >> Adoption is the sign of a respected and well designed language. > > > > I can think of numerous widely-adpoted languages that disprove that > > assertion, by nevertheless being poorly-designed languages that are > > loathed by the vast majority of programmers who use them. > > I'll have to agree to an extent. And you did remind me of PHP. So > there's that. > > But in a way PHP served an important purpose in its time. Important, yes. > In any case, it stands that, unless a programming language is so > ruined by bad design choices it is unusable, there is some kind of > merit to its ability to solve computational problems. That's a *very much* lower bar than your earlier claim I responded to: that “[widespread] adoption is the sign of a respected and well designed language”. > I can't stand Java. I just don't think calling it a mistake. It's > worth has been proven by its level of adoption and by the usable > software that has been made with it. Javascript/ECMAScript is > criticized by so many and yet there's no denying of its importance. You're making the case for importance, and capability to implement programs that solve problems. Maybe it's true, but it's irrelevant to the earlier point. It is quite separate from the language being well designed, and it is quite separate from the language being respectable. Many languages — some of which you've named — are poorly-designed, are not deserving of respect, despite being widely-adopted. > Even today we struggle to find a better alternative to client-side > scripting. Python is criticized by so many. And yet I don't think > calling on Python developers as an inferior breed of programmers. Glad to know that :-) -- \ “I have the simplest tastes. I am always satisfied with the | `\ best.” —Oscar Wilde | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Need Help w. PIP!
On 9/8/2015 6:19 PM, Cody Piersall wrote: On Sat, Sep 5, 2015 at 3:14 AM, Thomas 'PointedEars' Lahn mailto:pointede...@web.de>> wrote: > > Cody Piersall wrote: > > > Please respond to the list as well as the person you're actually talking > > to. It works out better for everyone that way. (You should just have to > > "reply all" instead of "reply"). [Reply] should send the reply to the list. > “Better” as in “getting/reading/downloading the same message *twice*”? > > The rule of thumb is: write here, read here. Some people email the list, but aren't subscribed to it. So I guess a better rule is to just reply-to-all for the OP? Please no, not as a routine. I intentionally read python-list as a newsgroup via gmane.news.org so I can pick messages as I feel like without my mailbox being flooded. Anyone who want to read responses to something they send can do so via gmane. Also, [Reply All] tends to collect multiple CC names, and most people don't have the curtesy to properly prune it. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Reply to author, reply to list, reply to all (was: Need Help w. PIP!)
Terry Reedy writes: > On 9/8/2015 6:19 PM, Cody Piersall wrote: > > On Sat, Sep 5, 2015 at 3:14 AM, Thomas 'PointedEars' Lahn > > mailto:pointede...@web.de>> wrote: > > > > > > Cody Piersall wrote: > > > > > > > Please respond to the list as well as the person you're > > > > actually talking to. It works out better for everyone that way. > > > > (You should just have to "reply all" instead of "reply"). > > [Reply] should send the reply to the list. The function named “reply” normally means “reply individually to the author”, and that's how it needs to stay. The “reply to the list” function is present in many mail clients, and works fine for this mailing list; Google Mail seems to be a notable exception that its users should ask to change. > > Some people email the list, but aren't subscribed to it. People who fit that description are not participants in the forum, so excluding them from forum replies is the right thing to do. > > So I guess a better rule is to just reply-to-all for the OP? > > Please no, not as a routine. Agreed. -- \ “Anyone who puts a small gloss on [a] fundamental technology, | `\ calls it proprietary, and then tries to keep others from | _o__) building on it, is a thief.” —Tim O'Reilly, 2000-01-25 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Reply to author, reply to list, reply to all (was: Need Help w. PIP!)
On 9 Sep 2015 07:11, "Ben Finney" wrote: > > Terry Reedy writes: > > > On 9/8/2015 6:19 PM, Cody Piersall wrote: > > > On Sat, Sep 5, 2015 at 3:14 AM, Thomas 'PointedEars' Lahn > > > mailto:pointede...@web.de>> wrote: > > > > > > > > Cody Piersall wrote: > > > > > > > > > Please respond to the list as well as the person you're > > > > > actually talking to. It works out better for everyone that way. > > > > > (You should just have to "reply all" instead of "reply"). > > > > [Reply] should send the reply to the list. > > The function named “reply” normally means “reply individually to the > author”, and that's how it needs to stay. > > The “reply to the list” function is present in many mail clients, and > works fine for this mailing list; Google Mail seems to be a notable > exception that its users should ask to change. > > > > Some people email the list, but aren't subscribed to it. > > People who fit that description are not participants in the forum, so > excluding them from forum replies is the right thing to do. > > > > So I guess a better rule is to just reply-to-all for the OP? > > > > Please no, not as a routine. > > Agreed. > > -- > \ “Anyone who puts a small gloss on [a] fundamental technology, | > `\ calls it proprietary, and then tries to keep others from | > _o__) building on it, is a thief.” —Tim O'Reilly, 2000-01-25 | > Ben Finney > > -- > https://mail.python.org/mailman/listinfo/python-list My question then is do you reply to all (with a clean cc list but including an OP from outside the list) in response to a persons question, even if the question is relatively simple. For me it's appreciated so that you know someone is dealing with it. But then it can also result in flooding your inbox. - Nick. -- https://mail.python.org/mailman/listinfo/python-list
