Re: Python Byte Code Hacking
On Thursday 14 July 2016 10:14, Ian Kelly wrote: > On Wed, Jul 13, 2016 at 12:48 PM, Vijay Kumar > wrote: >> Hi Everyone, >> I wrote an article on Python byte code hacking. The article is available >> from http://www.bravegnu.org/blog/python-byte-code-hacks.html The article >> uses an incremental approach for explaining Python's code objects and how to >> modify them. Unfortunately, I am stuck with Python 2, because Python 2 does >> not optimize out the divide operation, at compile time, and my example >> sequence depends on that behavior. > > def f(): > return g(6, 2) > > def g(a, b): > return a // b > > Now it can't optimize out the operation. I haven't had time to read the article yet, but is Vijay talking about Python's peekhole optimizer? It does constant folding, so that arithmetic expressions containing *only* constants will compile to the result: def f(): return 6//2 # compiles to "return 3" The simplest way to defeat that is to use a variable: def f(): x = 6 return x//2 The peephole optimizer is simple-minded enough that it won't pre-compute that. Let's check: py> import dis py> def f(): return 6//2 ... py> dis.dis(f) 1 0 LOAD_CONST 3 (3) 3 RETURN_VALUE py> def f(): ... x = 6 ... return x//2 ... py> dis.dis(f) 2 0 LOAD_CONST 1 (6) 3 STORE_FAST 0 (x) 3 6 LOAD_FAST0 (x) 9 LOAD_CONST 2 (2) 12 BINARY_FLOOR_DIVIDE 13 RETURN_VALUE -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
On Thursday 14 July 2016 15:18, Ian Kelly wrote: > Side note, neither do floating point numbers, really; what is often > called the mantissa is more properly known as the significand. But > integers don't have that either. Er, then what's a mantissa if it's not what people call a float's mantissa? What makes you say it is "more properly" known as the significand? I'm not necessarily disputing what you say, I'm wondering what is your justification for it. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Compression
I thought I'd experiment with some of Python's compression utilities. First I
thought I'd try compressing some extremely non-random data:
py> import codecs
py> data = "something non-random."*1000
py> len(data)
21000
py> len(codecs.encode(data, 'bz2'))
93
py> len(codecs.encode(data, 'zip'))
99
That's really good results. Both the bz2 and Gzip compressors have been able to
compress nearly all of the redundancy in the data.
What if we shuffle the data so it is more random?
py> import random
py> data = list(data)
py> random.shuffle(data)
py> data = ''.join(data)
py> len(data); len(codecs.encode(data, 'bz2'))
21000
10494
How about some really random data?
py> import string
py> data = ''.join(random.choice(string.ascii_letters) for i in range(21000))
py> len(codecs.encode(data, 'bz2'))
15220
That's actually better than I expected: it's found some redundancy and saved
about a quarter of the space. What if we try compressing data which has already
been compressed?
py> cdata = codecs.encode(data, 'bz2')
py> len(cdata); len(codecs.encode(cdata, 'bz2'))
15220
15688
There's no shrinkage at all; compression has actually increased the size.
What if we use some data which is random, but heavily biased?
py> values = string.ascii_letters + ("AABB")*100
py> data = ''.join(random.choice(values) for i in range(21000))
py> len(data); len(codecs.encode(data, 'bz2'))
21000
5034
So we can see that the bz2 compressor is capable of making use of deviations
from uniformity, but the more random the initial data is, the less effective is
will be.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
Re: problem writing excel sheet using python
On July 14, 2016 2:59:09 AM GMT+05:30, vineeth menneni wrote: >Hi I am finding it difficult to create a excel sheet using openpyxl or >xlsxwriter. The problem is that i am loading a table data from MYSQL db >which has 600k rows and 15 columns (approximately 100mb data). The >error that the terminal shows is that "MemoryError". I just wanted to >know if it is possible to create a excel sheet with the above said data >in less than one minute using any packages in python. > >Thanks, >Vineeth >-- >https://mail.python.org/mailman/listinfo/python-list Try saving data in csv format an then import it in excel George -- https://mail.python.org/mailman/listinfo/python-list
Re: Compression
Steven D'Aprano wrote: > How about some really random data? > > py> import string > py> data = ''.join(random.choice(string.ascii_letters) for i in > range(21000)) py> len(codecs.encode(data, 'bz2')) > 15220 > > That's actually better than I expected: it's found some redundancy and > saved about a quarter of the space. It didn't find any redundancy, it found the two unused bits: >>> math.log(len(string.ascii_letters), 2) 5.700439718141093 >>> 21000./8*_ 14963.654260120367 -- https://mail.python.org/mailman/listinfo/python-list
Re: Compression
On Thu, Jul 14, 2016 at 6:16 PM, Steven D'Aprano wrote: > How about some really random data? > > py> import string > py> data = ''.join(random.choice(string.ascii_letters) for i in range(21000)) > py> len(codecs.encode(data, 'bz2')) > 15220 > > That's actually better than I expected: it's found some redundancy and saved > about a quarter of the space. What it found was an imbalance in the frequencies of byte values - you used 52 values lots of times, and the other 204 never. Huffman coding means those 52 values will get fairly short codes, and if you happened to have just one or two other byte values, they'd be represented by longer codes. It's like the Morse code - by encoding some letters with very short sequences (dot followed by end-of-letter for E, dash followed by end-of-letter for T) and others with much longer sequences (dash-dot-dot-dash-EOL for X), it manages a fairly compact representation of typical English text. The average Morse sequence length for a letter is 3.19, but on real-world data... well, I used the body of your email as sample text (yes, I'm aware it's not all English), and calculated a weighted average of 2.60. (Non-alphabetics are ignored, and the text is case-folded.) Using the entire text of Gilbert & Sullivan's famous operettas, or the text of "The Beauty Stone", or the wikitext source of the Wikipedia article on Morse code, gave similar results (ranging from 2.56 to 2.60); interestingly, a large slab of Lorem Ipsum skewed the numbers slightly lower (2.52), not higher as I was afraid it would, being more 'random'. Further example: os.urandom() returns arbitrary byte values, and (in theory, at least) has equal probability of returning every possible value. Base 64 encoding that data makes three bytes come out as four. Check this out: >>> data = os.urandom(21000) >>> len(base64.b64encode(data)) # just to make sure 28000 >>> len(codecs.encode(data, 'bz2')) 21458 >>> len(codecs.encode(base64.b64encode(data), 'bz2')) 21290 When you remove the redundancy in b64-encoded data, you basically... get back what you started with. (Curiously, several repeated os.urandommings showed consistent results to the above - 214xx for direct 'compression' vs 212xx for b64-then-compress. But in both cases, it's larger than the 21000 bytes of input.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
EuroPython 2016: Getting your badge & ticket IDs
For this year, we have reconsidered the way we give out badges to try to reduce the queue lengths and your waiting time. Badges distributed based on ticket ID - To make finding badges easier, we have printed the ticket ID on each badge and will distribute badges based on ticket ID ranges. Each queue will be for one ticket ID range. Finding your ticket ID -- We will send all attendees an email with their ticket ID, but you can also look on the website to find your ticket ID. Simply log in and then check the ticket page to find your ticket preview: https://ep2016.europython.eu/p3/tickets/ The ticket ID is listed at the bottom of the ticket preview. If you forget your ticket ID, no worries. We will have a number of volunteers at the registration desk with a mobile app to quickly search the ticket database for your ticket. Simply ask them to help you find the right queue and you’re all set. Should they have trouble finding your ticket in the database, you’ll be asked to visit the registration counter to sort out any issues. Please check your ticket Please note that in order to find your tickets, the person who bought the ticket will have to have assigned the ticket to you, as we’ve outline in a previous blog post: http://blog.europython.eu/post/146895278207/europython-2016-please-configure-your-tickets We already know that there are a number of tickets which have not been assigned to the final attendee, so please double check that you can see your ticket on the ticket page after logging in to the website: https://ep2016.europython.eu/p3/tickets/ If you cannot find your ticket on that page, please ask the person who bought the ticket for you. The process for assigning the ticket is described in our blog post on the topic. If all else fails, simply write to our helpd...@europython.eu for help. Opening times of the registration desks --- These are the planned opening times of the registration desks where you can pick up your badge (or buy conference tickets or day passes). * Sunday, July 17 In the afternoon at 16:00, we will open the registration desk at the main conference venue, the Euskalduna Conference Center (ECC). It’ll stay open until around 19:00. You will be able to pick up the badges for your already purchased tickets as well as buy new ones at this registration desk. * Monday, July 18 The registration desk at the conference venue, the Euskalduna Conference Center (ECC), will open at 08:00 on Monday. Conference bag distribution --- We will do the bag stuffing on Sunday, starting at around 16:00 at the ECC. You’re welcome to come and help. The stuffed bags will then be distributed starting on Monday. With gravitational regards, -- EuroPython 2016 Team http://ep2016.europython.eu/ http://www.europython-society.org/ PS: Please forward or retweet to help us reach all interested parties: https://twitter.com/europython/status/753553441239293954 Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Scapy: sniff(filter='icmp', iface='ppp0', prn=icmp_callback)
#!/usr/bin/python
import logging
logging.getLogger("scapy.runtime").setLevel(logging.ERROR)
from scapy.all import TCP, IP, ICMP, sniff
def ip_callback(pkt):
print '--- IP--'
pkt.show()
print 'IP', pkt.src, pkt.sport, '--->', pkt.dst, pkt.dport
def icmp_callback(pkt):
print '--- ICMP --'
print pkt.show()
def tcp_callback(pkt):
pkt.show()
print 'TCP', pkt.src, pkt.sport, '--->', pkt.dst, pkt.dport
def udp_callback(pkt):
pkt.show()
print 'UDP', pkt.src, pkt.sport, '--->', pkt.dst, pkt.dport
print 'hello'
sniff(filter='icmp', iface='ppp0', prn=icmp_callback)
I get:
deathstar> python myscapy.py
hello
and nothing further when ping -c 2 8.8.8.8 runs - why??
Sometimes though it works (once in a blue moon) and i get the show
output.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
On Jul 14, 2016 1:52 AM, "Steven D'Aprano" wrote: > > On Thursday 14 July 2016 15:18, Ian Kelly wrote: > > > Side note, neither do floating point numbers, really; what is often > > called the mantissa is more properly known as the significand. But > > integers don't have that either. > > > Er, then what's a mantissa if it's not what people call a float's mantissa? > > What makes you say it is "more properly" known as the significand? > > I'm not necessarily disputing what you say, I'm wondering what is your > justification for it. http://mathworld.wolfram.com/Significand.html http://mathworld.wolfram.com/Mantissa.html The significand of -3.14159 is the sequence of digits 314159. The mantissa of -3.14159 is the number 0.85841. I don't have a copy of the IEEE-754 standard, but I believe that it also uses the term "significand" and specifically avoids the term "mantissa". -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
On 2016-07-14 15:30, Ian Kelly wrote: On Jul 14, 2016 1:52 AM, "Steven D'Aprano" wrote: On Thursday 14 July 2016 15:18, Ian Kelly wrote: Side note, neither do floating point numbers, really; what is often called the mantissa is more properly known as the significand. But integers don't have that either. Er, then what's a mantissa if it's not what people call a float's mantissa? What makes you say it is "more properly" known as the significand? I'm not necessarily disputing what you say, I'm wondering what is your justification for it. http://mathworld.wolfram.com/Significand.html http://mathworld.wolfram.com/Mantissa.html The significand of -3.14159 is the sequence of digits 314159. The mantissa of -3.14159 is the number 0.85841. I don't have a copy of the IEEE-754 standard, but I believe that it also uses the term "significand" and specifically avoids the term "mantissa". Confirmed. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
Ian Kelly : > The significand of -3.14159 is the sequence of digits 314159. The > mantissa of -3.14159 is the number 0.85841. Fight it all you want. However: In American English, the original word for [significand] seems to have been mantissa (Burks[1] et al.), and this usage remains common in computing and among computer scientists. https://en.wikipedia.org/wiki/Significand#Use_of_.22mantissa.22> This digit string is referred to as the significand, mantissa, or coefficient. https://en.wikipedia.org/wiki/Floating_point#Floating-point_numbers> and, FWIW: Liukulukuun kuuluu neljä osaa: etumerkki (s), mantissa (m), kantaluku (k) ja eksponentti (c). [...] x = (−1)^s mk^c. https://fi.wikipedia.org/wiki/Liukuluku> Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
On Thu, Jul 14, 2016 at 10:02 AM, Marko Rauhamaa wrote: > Ian Kelly : > >> The significand of -3.14159 is the sequence of digits 314159. The >> mantissa of -3.14159 is the number 0.85841. > > Fight it all you want. However: > >In American English, the original word for [significand] seems to >have been mantissa (Burks[1] et al.), and this usage remains common >in computing and among computer scientists. >https://en.wikipedia.org/wiki/Significand#Use_of_.22mantissa.22> Just because it's already common to use the wrong term doesn't mean the usage should be promulgated further. -- https://mail.python.org/mailman/listinfo/python-list
Don't understand why I'm getting this error
Hi all. I've been looking at this for a bit, and can't seem to come to a possible conclusion on what could be happening to get an error. Anyway, here is the code, then I'll explain. http://pastebin.com/raw/YPiTfWbG the issue comes when using argv. But when I change TIME = argv to TIME = 2 It does exactly what I intended, no issues. What's wrong? Thanks for any help. Also, The error I get when trying to run is: Traceback (most recent call last): File "sound_recorder.py", line 21, in for i in range(0, int(RATE / CHUNK * TIME)): OverflowError: range() result has too many items -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
Ian Kelly : > On Thu, Jul 14, 2016 at 10:02 AM, Marko Rauhamaa wrote: >>In American English, the original word for [significand] seems to >>have been mantissa (Burks[1] et al.), and this usage remains >>common in computing and among computer scientists. >https://en.wikipedia.org/wiki/Significand#Use_of_.22mantissa.22> > > Just because it's already common to use the wrong term doesn't mean > the usage should be promulgated further. Where do you get the idea that the common usage is "wrong?" What do you use as a standard? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Don't understand why I'm getting this error
On Thursday, July 14, 2016 at 10:39:35 AM UTC-7, Carter Temm wrote: > Hi all. > I've been looking at this for a bit, and can't seem to come to a possible > conclusion on what could be happening to get an error. Anyway, here is the > code, then I'll explain. > > http://pastebin.com/raw/YPiTfWbG > > the issue comes when using argv. But when I change > > TIME = argv > > to > > TIME = 2 > > It does exactly what I intended, no issues. What's wrong? Thanks for any help. > > > > Also, The error I get when trying to run is: Traceback (most recent call > last): File "sound_recorder.py", line 21, in for i in range(0, > int(RATE / CHUNK * TIME)): OverflowError: range() result has too many items argv is a list containing the name (or path depending on OS) of the script and all the command line parameters passed to it. I suspect that the problem is that the contents of argv will be strings, but you need TIME to be an integer. Even if you use "python myScript.py 5", argv[1] will be a string because Python doesn't know if "5" is actually supposed to be an integer, or if your script might be expecting a file name, and you have a file named "5". An OverflowError when using range(..) usually means your range is too big. I'm assuming you're using Python 2.x. Try printing int(RATE / CHUNK * TIME) to see if the value is what you're expecting. Also consider using xrange(..). It doesn't require the entire list to be stored in memory. -- https://mail.python.org/mailman/listinfo/python-list
Re: Don't understand why I'm getting this error
Carter Temm wrote: > Hi all. > I've been looking at this for a bit, and can't seem to come to a possible > conclusion on what could be happening to get an error. Anyway, here is the > code, then I'll explain. > > http://pastebin.com/raw/YPiTfWbG > > the issue comes when using argv. But when I change > > TIME = argv > > to > > TIME = 2 > > It does exactly what I intended, no issues. What's wrong? Thanks for any help. > > Also, The error I get when trying to run is: Traceback (most recent call > last): File "sound_recorder.py", line 21, in for i in range(0, > int(RATE / CHUNK * TIME)): OverflowError: range() result has too many items > Offhand, I'll bet that you're getting TIME="2" instead of TIME=2. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: Don't understand why I'm getting this error
Carter Temm wrote: > Hi all. > I've been looking at this for a bit, and can't seem to come to a possible > conclusion on what could be happening to get an error. Anyway, here is the > code, then I'll explain. > > http://pastebin.com/raw/YPiTfWbG > > the issue comes when using argv. But when I change > > TIME = argv > > to > > TIME = 2 > > It does exactly what I intended, no issues. What's wrong? Thanks for any > help. > > > > Also, The error I get when trying to run is: Traceback (most recent call > last): File "sound_recorder.py", line 21, in for i in range(0, > int(RATE / CHUNK * TIME)): OverflowError: range() result has too many > items RATE/CHUNK is an integer, but TIME when extracted from sys.argv is a str. The * operator tells python to repeat the string RATE/CHUNK times: >>> RATE = 44100 >>> CHUNK = 1024 >>> TIME = "2" >>> RATE/CHUNK * TIME '222' You need to convert TIME to an int before evaluating the expression to get the expected result: >>> RATE/CHUNK * int(TIME) 86 -- https://mail.python.org/mailman/listinfo/python-list
Re: Were is a great place to Share your finished projects?
Michael Torrie writes: >I understand that in Python's case, pure cost wins out. Python.org >could host a GitLab instance, which contains the repo tools plus ticket >tracking, etc, and ordinary developers could push their changes to their >own public git repos and send in pull requests and it would all work >swimmingly. However this comes at considerable cost in terms of >maintenance of the server and server software. So I can understand the >allure of GitHub. It's shiny and free-ish. Python's primary repository is Mercurial (hg.python.org), not Git. Were python to switch, it wouldn't be too much work to just deploy gitlab (or whatever) instead of mercurial. However, I see nothing git offers over mercurial. -- H -- https://mail.python.org/mailman/listinfo/python-list
Re: Were is a great place to Share your finished projects?
On 7/14/2016 3:04 PM, hasan.di...@gmail.com wrote: Python's primary repository is Mercurial (hg.python.org), not Git. CPython's current repository Ditto for the PSF Python docs. Were python to switch, Like it or not, CPython and the Docs are moving to git and github. PEPs and the devguide have already been moved. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging multiple wheels in the same package
Appreciate it! Will do! -- https://mail.python.org/mailman/listinfo/python-list
Re: Were is a great place to Share your finished projects?
On Friday, July 15, 2016 at 7:04:14 AM UTC+12, hasan...@gmail.com wrote: > ... I see nothing git offers over mercurial. Except greater productivity. -- https://mail.python.org/mailman/listinfo/python-list
Re: Were is a great place to Share your finished projects?
A lot of these arguments and points have already been made and hashed out on the python-dev list. There's a very good article that one of the python core developers wrote about the decision to move to github http://www.snarky.ca/the-history-behind-the-decision-to-move-python-to-github Basically, maintaining an open source git server, bug tracker, etc. would have cost time and money, and historically very few people were willing to contribute those, especially the people who were the most opinionated on the desire to remain "pure to open source". Github gives all these things away for free. And pretty much every python developer has already used github for other projects. In the article he makes a good point that if you're that worried about always using open-source, then you shouldn't be using gmail, or twitter, or even automobiles, since they all use software that is closed-source. At some point, paying for software just makes sense. On Thu, Jul 14, 2016 at 12:34 PM, Terry Reedy wrote: > On 7/14/2016 3:04 PM, hasan.di...@gmail.com wrote: > > Python's primary repository is Mercurial (hg.python.org), not Git. >> > > CPython's current repository > Ditto for the PSF Python docs. > > Were python to switch, >> > > Like it or not, CPython and the Docs are moving to git and github. > PEPs and the devguide have already been moved. > > -- > Terry Jan Reedy > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
On Friday, July 15, 2016 at 5:11:46 AM UTC+12, Ian wrote: > Just because it's already common to use the wrong term doesn't mean > the usage should be promulgated further. Yes of course. The only logically-acceptable meaning of “mantissa” is “female mantis”, and any other usage is to be the immediate target of derisive laughter and scorn. -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
On Jul 14, 2016 11:37 AM, "Marko Rauhamaa" wrote: > > Ian Kelly : > > On Thu, Jul 14, 2016 at 10:02 AM, Marko Rauhamaa wrote: > >>In American English, the original word for [significand] seems to > >>have been mantissa (Burks[1] et al.), and this usage remains > >>common in computing and among computer scientists. >>https://en.wikipedia.org/wiki/Significand#Use_of_.22mantissa.22> > > > > Just because it's already common to use the wrong term doesn't mean > > the usage should be promulgated further. > > Where do you get the idea that the common usage is "wrong?" What do you > use as a standard? Is it "wrong" to consider some usages "wrong"? By what standard? I'm not interested in arguing over philosophy, so I won't. -- https://mail.python.org/mailman/listinfo/python-list
Re: Were is a great place to Share your finished projects?
On Fri, 15 Jul 2016 09:04 am, Lawrence D’Oliveiro wrote: > On Friday, July 15, 2016 at 7:04:14 AM UTC+12, hasan...@gmail.com wrote: > >> ... I see nothing git offers over mercurial. > > Except greater productivity. That has not been even close to my experience. And I don't mean my *personal* experience. About seven years ago, the senior technical manager at my work chose hg over git. When he left to go to greener pastures, the dev team took about 30 seconds to to reverse his decision and migrate to git, after which the level of VCS-related screw-ups and queries went through the roof. To give you an idea of how screwed up things are, even though I'm not one of the developer team, and have never pushed a thing into the code repositories (I have pushed into documentation repos), somehow according to "git blame" I'm responsible for a bunch of code. (If I'd been paid for this code I didn't write, I wouldn't mind so much...) -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Were is a great place to Share your finished projects?
On Fri, 15 Jul 2016 09:13 am, Brendan Abel wrote: > In the article he makes a good point that if > you're that worried about always using open-source, then you shouldn't be > using gmail, or twitter, or even automobiles, It's not a good point. I don't use gmail, or twitter, and if I could find a car that didn't rely on closed-source code, I would use it. Just because choice is limited and its hard or impossible to get open-source engines doesn't mean that closed-source engines are a good idea. > since they all use software > that is closed-source. At some point, paying for software just makes > sense. No, that doesn't follow. The opposite of "open source" is not "paying for software". You can pay somebody to maintain your open source repo just as easily as you can pay somebody else to maintain their own closed source repo. I watched the discussion on Python-Dev that decided to move to github, and there were completely viable open source hg alternatives. Although nobody was quite crass enough to come right out and say it, the alternatives were all dismissed because they weren't Github, because "everyone uses github". -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
On Friday, July 15, 2016 at 12:17:27 PM UTC+12, Ian wrote:
> Is it "wrong" to consider some usages "wrong"? By what standard?
Do you say “head over heels” or “heels over head”? “Burgle” or “burglari{s,z}e”?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Were is a great place to Share your finished projects?
Steven D'Aprano writes: > On Fri, 15 Jul 2016 09:13 am, Brendan Abel wrote: > > since they all use software that is closed-source. At some point, > > paying for software just makes sense. Is it 1998 again already? Or am I expecting too much that people involved in software in the 21st century should not fall for the canard of “why don't you want to pay for software”, because it is *completely irrelevant* to the issue of software freedom. So please, stop repeating that canard. Of course paying for software makes sense. That in no way entails vendor lock-in of valuable community data, and we should not be paying for that. > No, that doesn't follow. The opposite of "open source" is not "paying > for software". You can pay somebody to maintain your open source repo > just as easily as you can pay somebody else to maintain their own > closed source repo. Yes. Likewise, just because you don't hand any money to someone doesn't mean you are free from vendor lock-in and proprietary protocols. One day perhaps we won't need to repeat that for it to be understood. > I watched the discussion on Python-Dev that decided to move to github, > and there were completely viable open source hg alternatives. Although > nobody was quite crass enough to come right out and say it, the > alternatives were all dismissed because they weren't Github, because > "everyone uses github". Fortunately there are a zillion software projects who can still choose a hosting provider that won't lock them in, and good free-software hosting alternatives like Pagure are beginning to appear. Not all is lost. -- \ “The Initial Mystery that attends any journey is: how did the | `\ traveller reach his starting point in the first place?” —Louise | _o__) Bogan, _Journey Around My Room_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious Omission In New-Style Formats
Ian Kelly : > On Jul 14, 2016 11:37 AM, "Marko Rauhamaa" wrote: >> Where do you get the idea that the common usage is "wrong?" What do >> you use as a standard? > > Is it "wrong" to consider some usages "wrong"? By what standard? > > I'm not interested in arguing over philosophy, so I won't. Common usage among educated speakers ordinarily is the yardstick for language questions. However, I'm cool with "cuz I say so." Marko -- https://mail.python.org/mailman/listinfo/python-list
