Re: Curious Omission In New-Style Formats

[Marko Rauhamaa]

Ian Kelly :

> I don't know of anybody who would consider that good design, and the
> "precision" field in printf-style formatting isn't good design either.
> But it has history behind it, so does that put it in the right?

Apparently, the original intent for the field was for precision only,
and the syntax of placing the precision after a dot reinforces the
notion. Later, the field found other neat uses and people didn't think
of going back and renaming the field in source code and all of the
documentation.

For Unix hackers, this was a neat trick, a laudable hack.

A somewhat similar example is the "execute" permission flag on Unix
files. On regular files, it expresses whether the file can be executed.
On directory files, it expresses whether it can be "entered".

Just as you can enter into philosophical discussions about whether
integers or strings can have a precision, you can debate whether a
directory can be executed.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Were is a great place to Share your finished projects?

[Chris Angelico]

On Wed, Jul 13, 2016 at 4:44 PM, Steven D'Aprano
 wrote:
> Even if Github was 100% open source with no proprietary extensions, and the
> *technical* cost of leaving was low, the single-network effect would still 
> lock
> you in, which leaves you (to some degree) at the mercy of Github's management.
> Don't like the fact that they run their servers on electricity made from
> burning puppies and the tears of little children? Too bad, what are you going
> to do, move your project to some backwater VCS where nobody ever goes? You
> might as well be on AOL for all anyone will ever find your project.

So what're you going to do? Move *now* to some backwater where nobody
ever goes, just in case GitHub ever turns evil?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Lawrence D’Oliveiro]

On Wednesday, July 13, 2016 at 6:22:31 PM UTC+12, Ian wrote:

> I never claimed it's not useful. I don't really have a problem with
> format supporting it, either. But if it does, then don't call it
> "precision".

Like it or not, that is the accepted term, as used in the printf(3) man page.

Feel free not to use common accepted terms if you don’t want. You can use words 
to mean whatever you avocado, but don’t expect other people to carrot.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Were is a great place to Share your finished projects?

[Steven D'Aprano]

On Wednesday 13 July 2016 17:00, Chris Angelico wrote:

> On Wed, Jul 13, 2016 at 4:44 PM, Steven D'Aprano
>  wrote:
>> Even if Github was 100% open source with no proprietary extensions, and the
>> *technical* cost of leaving was low, the single-network effect would still
>> lock you in, which leaves you (to some degree) at the mercy of Github's
>> management. Don't like the fact that they run their servers on electricity
>> made from burning puppies and the tears of little children? Too bad, what
>> are you going to do, move your project to some backwater VCS where nobody
>> ever goes? You might as well be on AOL for all anyone will ever find your
>> project.
> 
> So what're you going to do? Move *now* to some backwater where nobody
> ever goes, just in case GitHub ever turns evil?

Move *now* to a viable alternative, while it's still viable and before it's too 
late, in order to encourage competition and discourage those idiots who don't 
know how to use Google and think Github is the entire Internet-for-code.

"I couldn't find it on Github, therefore it doesn't exist" is already a real 
phenomenon. Fortunately, at this point you probably won't want to accept 
patches from those people. But in five or ten years? I give odds of about 50:50 
that even competent coders will have bought into the Github-is-the-universe, 
just as even people who know better treat Facebook as the entire Internet, and 
worse.


"...some backwater where nobody ever goes..."

If you really mean that, then you're saying that Github has already captured 
such a dominant market share that they are an effective monopoly over all 
hosted DVCSes, and that programmers no longer have a choice about using them. 
Its Github, or you're invisible, and leaving is not an option.

If you mean that, then be honest:

"The horse has already bolted, and vendor lockin is not a concern, its a fact. 
All I can do is *hope* that Github doesn't turn evil."

On the other hand, if you genuinely think that Github *hasn't* captured the 
market, that migration away from them is still an option, then you've undercut 
your argument against using competing services. If you genuinely think that 
migrating away from Github to (let's say) Bitbucket is an option, then your 
quip about backwaters is invalid.



Speaking of F/B, a true story. A friend of mine in the US had this conversation 
(edited for brevity):

"You got married??!? When did you get married?"

"Oh, about three months ago."

"I'm disappointed that you didn't invite me. I would have loved to have come."

"What do you mean? I posted the details on my Wall. Didn't you see it?"



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Steven D'Aprano]

On Wednesday 13 July 2016 17:05, Lawrence D’Oliveiro wrote:

> On Wednesday, July 13, 2016 at 6:22:31 PM UTC+12, Ian wrote:
> 
>> I never claimed it's not useful. I don't really have a problem with
>> format supporting it, either. But if it does, then don't call it
>> "precision".
> 
> Like it or not, that is the accepted term, as used in the printf(3) man page.
> 
> Feel free not to use common accepted terms if you don’t want. You can use
> words to mean whatever you avocado, but don’t expect other people to carrot.

+1 QOTW


-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Were is a great place to Share your finished projects?

[Chris Angelico]

On Wed, Jul 13, 2016 at 6:49 PM, Steven D'Aprano
 wrote:
>> what
>> are you going to do, move your project to some backwater VCS where nobody
>> ever goes?
>
> "...some backwater where nobody ever goes..."
>
> If you really mean that, then you're saying that Github has already captured
> such a dominant market share that they are an effective monopoly over all
> hosted DVCSes, and that programmers no longer have a choice about using them.
> Its Github, or you're invisible, and leaving is not an option.

Your words, not mine.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[jonas . thornvall]

Den onsdag 13 juli 2016 kl. 04:29:48 UTC+2 skrev Steven D'Aprano:
> On Wed, 13 Jul 2016 03:35 am, jonas.thornv...@gmail.com wrote:
> 
> > No it is only compressible down to a limit given by the algorithm.
> 
> Right! Then there is data that you can't compress.
> 
> Suppose you have some data:
> 
> data = "ABABABABABAB...ABAB"
> 
> And you compress it "down to a limit":
> 
> x = compress(compress(compress(data)))
> print(x)
> => prints "@nx7%k!b"
> 
> Now let's try again with something else:
> 
> data = "AABBB..."
> 
> And you compress it "down to a limit":
> 
> x = compress(compress(compress(compress(data
> print(x)
> => prints "wu*$cS#k-pv32zx[&+r"
> 
> 
> One more time:
> 
> data = "AABBAABBAABBAABBAABB"
> x = compress(data)
> print(x)
> => prints "g^x3@"
> 
> 
> We agree on this. Now you say, "Give me some random data, anything at all,
> and I'll compress it!", and I run a random number generator and out pops:
> 
> data = "@nx7%k!b"
> 
> or possibly:
> 
> data = "wu*$cS#k-pv32zx[&+r"
> 
> or:
> 
> data = "g^x3@"
> 
> 
> and I say "Compress that!"
> 
> But we've already agreed that this is as compressed as you can possibly make
> it. You can't compress it any more.
> 
> So there's *at least some* random data that you can't compress. Surely you
> have to accept that. You don't get to say "Oh, I don't mean *that* data, I
> mean only data that I can compress". Random data means its random, you
> don't get to pick and choose between data you can compress and data that
> you can't.
> 
> Now the tricky part is to realise that its not just short sequences of
> random data that can't be compressed. The same applies for LONG sequences
> to. If I give you a gigabyte of raw video, you can probably compress that a
> fair bit. That's what things like x264 encoders do. The x265 encoder is
> even better. But they're lossy, so you can't reverse them.
> 
> But if I give you a gigabyte of random data, you'll be lucky to find *any*
> patterns or redundancies that allow compression. You might be able to
> shrink the file by a few KB. And if you take that already compressed file,
> and try to compress it again, well, you've already hit the limit of
> compression. There no more redundancy left to remove.
> 
> It doesn't matter how clever you are, or what a "folding structure" is, or
> how many times you iterate over the data. It's a matter of absolute
> simplicity: the pigeonhole principle. You can't argue with the numbers.
> 
> If you start with a 100 digit decimal number, there are 10**100 different
> pigeons. If you can compress down to a 6 digit decimal number, there are
> 10**6 pigeon holes. You cannot put 10*100 pigeons into 10**6 pigeon holes
> without doubling up (which makes your compression lossly).
> 
> So either some numbers cannot be compressed, or some numbers are compressed
> to the same result, and you can't tell which was the original. That's your
> choice: a lossless encoder means some numbers can't be compressed, a lossy
> encoder means you can't reverse the process exactly.
> 
> 
> 
> 
> 
> -- 
> Steven
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.

It is not that the data is not compressible i just need more chunks or random 
data, it is the footprint of the algorithm that has a certain it is a structure 
afterall albeit richer in interpretation than the numerical field.

You exchange size for computational complexity, but that may be true for any 
compression algorithm.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[jonas . thornvall]

Den onsdag 13 juli 2016 kl. 04:29:48 UTC+2 skrev Steven D'Aprano:
> On Wed, 13 Jul 2016 03:35 am, jonas.thornv...@gmail.com wrote:
> 
> > No it is only compressible down to a limit given by the algorithm.
> 
> Right! Then there is data that you can't compress.
> 
> Suppose you have some data:
> 
> data = "ABABABABABAB...ABAB"
> 
> And you compress it "down to a limit":
> 
> x = compress(compress(compress(data)))
> print(x)
> => prints "@nx7%k!b"
> 
> Now let's try again with something else:
> 
> data = "AABBB..."
> 
> And you compress it "down to a limit":
> 
> x = compress(compress(compress(compress(data
> print(x)
> => prints "wu*$cS#k-pv32zx[&+r"
> 
> 
> One more time:
> 
> data = "AABBAABBAABBAABBAABB"
> x = compress(data)
> print(x)
> => prints "g^x3@"
> 
> 
> We agree on this. Now you say, "Give me some random data, anything at all,
> and I'll compress it!", and I run a random number generator and out pops:
> 
> data = "@nx7%k!b"
> 
> or possibly:
> 
> data = "wu*$cS#k-pv32zx[&+r"
> 
> or:
> 
> data = "g^x3@"
> 
> 
> and I say "Compress that!"
> 
> But we've already agreed that this is as compressed as you can possibly make
> it. You can't compress it any more.
> 
> So there's *at least some* random data that you can't compress. Surely you
> have to accept that. You don't get to say "Oh, I don't mean *that* data, I
> mean only data that I can compress". Random data means its random, you
> don't get to pick and choose between data you can compress and data that
> you can't.
> 
> Now the tricky part is to realise that its not just short sequences of
> random data that can't be compressed. The same applies for LONG sequences
> to. If I give you a gigabyte of raw video, you can probably compress that a
> fair bit. That's what things like x264 encoders do. The x265 encoder is
> even better. But they're lossy, so you can't reverse them.
> 
> But if I give you a gigabyte of random data, you'll be lucky to find *any*
> patterns or redundancies that allow compression. You might be able to
> shrink the file by a few KB. And if you take that already compressed file,
> and try to compress it again, well, you've already hit the limit of
> compression. There no more redundancy left to remove.
> 
> It doesn't matter how clever you are, or what a "folding structure" is, or
> how many times you iterate over the data. It's a matter of absolute
> simplicity: the pigeonhole principle. You can't argue with the numbers.
> 
> If you start with a 100 digit decimal number, there are 10**100 different
> pigeons. If you can compress down to a 6 digit decimal number, there are
> 10**6 pigeon holes. You cannot put 10*100 pigeons into 10**6 pigeon holes
> without doubling up (which makes your compression lossly).
> 
> So either some numbers cannot be compressed, or some numbers are compressed
> to the same result, and you can't tell which was the original. That's your
> choice: a lossless encoder means some numbers can't be compressed, a lossy
> encoder means you can't reverse the process exactly.
> 
> 
> 
> 
> 
> -- 
> Steven
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.

Ok, try to see it this way very big numbers can be described as the sum 
or difference between a sequense of a few polynomials. Unfortunately we lack 
the computational skill/computing power to find them.

That is not the case using foldings/geometric series.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[jonas . thornvall]

Den onsdag 13 juli 2016 kl. 12:05:03 UTC+2 skrev jonas.t...@gmail.com:
> Den onsdag 13 juli 2016 kl. 04:29:48 UTC+2 skrev Steven D'Aprano:
> > On Wed, 13 Jul 2016 03:35 am, jonas.thornv...@gmail.com wrote:
> > 
> > > No it is only compressible down to a limit given by the algorithm.
> > 
> > Right! Then there is data that you can't compress.
> > 
> > Suppose you have some data:
> > 
> > data = "ABABABABABAB...ABAB"
> > 
> > And you compress it "down to a limit":
> > 
> > x = compress(compress(compress(data)))
> > print(x)
> > => prints "@nx7%k!b"
> > 
> > Now let's try again with something else:
> > 
> > data = "AABBB..."
> > 
> > And you compress it "down to a limit":
> > 
> > x = compress(compress(compress(compress(data
> > print(x)
> > => prints "wu*$cS#k-pv32zx[&+r"
> > 
> > 
> > One more time:
> > 
> > data = "AABBAABBAABBAABBAABB"
> > x = compress(data)
> > print(x)
> > => prints "g^x3@"
> > 
> > 
> > We agree on this. Now you say, "Give me some random data, anything at all,
> > and I'll compress it!", and I run a random number generator and out pops:
> > 
> > data = "@nx7%k!b"
> > 
> > or possibly:
> > 
> > data = "wu*$cS#k-pv32zx[&+r"
> > 
> > or:
> > 
> > data = "g^x3@"
> > 
> > 
> > and I say "Compress that!"
> > 
> > But we've already agreed that this is as compressed as you can possibly make
> > it. You can't compress it any more.
> > 
> > So there's *at least some* random data that you can't compress. Surely you
> > have to accept that. You don't get to say "Oh, I don't mean *that* data, I
> > mean only data that I can compress". Random data means its random, you
> > don't get to pick and choose between data you can compress and data that
> > you can't.
> > 
> > Now the tricky part is to realise that its not just short sequences of
> > random data that can't be compressed. The same applies for LONG sequences
> > to. If I give you a gigabyte of raw video, you can probably compress that a
> > fair bit. That's what things like x264 encoders do. The x265 encoder is
> > even better. But they're lossy, so you can't reverse them.
> > 
> > But if I give you a gigabyte of random data, you'll be lucky to find *any*
> > patterns or redundancies that allow compression. You might be able to
> > shrink the file by a few KB. And if you take that already compressed file,
> > and try to compress it again, well, you've already hit the limit of
> > compression. There no more redundancy left to remove.
> > 
> > It doesn't matter how clever you are, or what a "folding structure" is, or
> > how many times you iterate over the data. It's a matter of absolute
> > simplicity: the pigeonhole principle. You can't argue with the numbers.
> > 
> > If you start with a 100 digit decimal number, there are 10**100 different
> > pigeons. If you can compress down to a 6 digit decimal number, there are
> > 10**6 pigeon holes. You cannot put 10*100 pigeons into 10**6 pigeon holes
> > without doubling up (which makes your compression lossly).
> > 
> > So either some numbers cannot be compressed, or some numbers are compressed
> > to the same result, and you can't tell which was the original. That's your
> > choice: a lossless encoder means some numbers can't be compressed, a lossy
> > encoder means you can't reverse the process exactly.
> > 
> > 
> > 
> > 
> > 
> > -- 
> > Steven
> > “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> > enough, things got worse.
> 
> Ok, try to see it this way very big numbers can be described as the 
> sum or difference between a sequense of a few polynomials. Unfortunately we 
> lack the computational skill/computing power to find them.
> 
> That is not the case using foldings/geometric series.

The sum or difference of a few small polynomials would still of course be a 
polynomial. But as i say it is a case of enrich the interpretation of the 
symbolic set that you look at you replace digits bits/integers with arithmetic 
describing them.
-- 
https://mail.python.org/mailman/listinfo/python-list

EuroPython 2016: Guggenheim and Fine Arts Museum

[M.-A. Lemburg]

EuroPython is not the only attraction in Bilbao to attend in July. The
city also hosts the famous Guggenheim Museum, featuring modern art in
an amazing building designed by Frank O. Gehry.

>>> Please see below for a special deal we have for EuroPython attendees

  *** Guggenheim Museum ***

   https://ep2016.europython.eu/en/venue/guggenheim-museum/


You can also find the Fine Arts Museum in Bilbao, with exhibitions of
Tucker and 50s fashion in France, in addition to other
masterpieces. It is very close to the conference venue.

   *** Fine Arts Museum ***

   https://ep2016.europython.eu/en/venue/fine-arts-museum/



Special offer for EuroPython attendees: Avoid long queues
-

If you want to avoid long queues at the Guggenheim Museum, you can
benefit from getting a ticket at the conference desk.

We have acquired a block of tickets and will give them away for free,
if you donate at least EUR 10 to the EuroPython conference financial
aid budget for next year.

That’s less than the regular ticket price and you get the additional
warm fuzzy feeling of helping others as bonus :-)

Donations can be made in cash at the conference desk.


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/753158920781332481
Thanks.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[Steven D'Aprano]

On Wed, 13 Jul 2016 08:04 pm, jonas.thornv...@gmail.com wrote:

> Ok, try to see it this way very big numbers can be described as
> the sum or difference between a sequense of a few polynomials.

*Any* number, big or small, can be given as the sum or difference of a few
polynomials:

15 = (25*x**2 - 2*x + 40) - (25*x**2 - 2*x + 25)

But... why am I wasting my time with the x**2 and x terms? They must
*always* cancel, because I'm trying to simplify to a constant. So I should
just write:

15 = 40 - 25

but that's a waste of time to. I should just write:

15 

and be done. The same applies for any number, no matter how big.


> Unfortunately we lack the computational skill/computing power to find
> them.
> 
> That is not the case using foldings/geometric series.

You still haven't explained how you are supposed to compress 10**100
possible inputs to just 10**6 outputs without any loss of information.






-- 
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: Program outlining

[Rustom Mody]

On Monday, July 11, 2016 at 6:27:05 PM UTC+5:30, Rustom Mody wrote:
> On Monday, July 11, 2016 at 6:26:01 PM UTC+5:30, Rustom Mody wrote:
> > Ive been trying to figure out the best outlining that emacs can give for
> > programs.
> 
> Oops sorry! Wrong list!!

Couple of people wrote me off list asking what I found/know on this.
Its collected here – its really notes for my students so not very well polished 
:-)

http://blog.languager.org/2016/07/emacs-tips.html

There’s one section specifically on “Programming Language Support”
And some titbits on specific languages including python
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Packaging multiple wheels in the same package

[Nir Cohen]

On Thursday, July 7, 2016 at 7:47:22 AM UTC+3, Nir Cohen wrote:
> On Wednesday, July 6, 2016 at 10:09:01 PM UTC+3, Ethan Furman wrote:
> > On 07/06/2016 11:43 AM, Nir Cohen wrote:
> > 
> > > We decided that we want to package sets of wheels together created or 
> > > downloaded
> >  > by `pip wheel`, add relevant metadata, package them together into a 
> > single archive
> >  > (tar.gz or zip) and use the same tool which packs them up to install 
> > them later on,
> >  > on the destination hosts.
> > >
> > > We came up with a tool (http://github.com/cloudify-cosmo/wagon) to do 
> > > just that
> >  > and that's what we currently use to create and install our plugins.
> > 
> > Sounds like a great idea!
> > 
> > Once you have your feed-back from here you'll want to take your PEP over 
> > to the dist-utils sig:
> > 
> > https://mail.python.org/mailman/listinfo/distutils-sig
> > 
> > --
> > ~Ethan~
> 
> Happy to hear :)
> 
> btw, pull requests are certainly welcome to make whichever changes required 
> to make Wagon PEP-worthy.


Sorry to bump this up.. but I'm not sure exactly how I should go about getting 
as much feedback as possible on this. Any suggestions?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Chris Angelico]

On Wed, Jul 13, 2016 at 9:46 PM, Dennis Lee Bieber
 wrote:
> On Wed, 13 Jul 2016 00:21:17 -0600, Ian Kelly 
> declaimed the following:
>
>>What if I've been doing my math with fixed-point integers (because I
>>don't know about or just don't like decimals), and now I want to
>>format them for output? Is this just wrong?
>>
>>'{:.2f}'.format(int_value / 100)
>>
>
> Ugh... After using integers to keep accuracy in the LSB, you know toss
> it out the window by converting to a float which may have an inexact
> representation.
>
> Presuming you kept track of the decimal place during all those integer
> operations, format as an integer, then split it at the decimal and insert a
> "." at the spot.

Or just use divmod:

>>> "%d.%02d" % divmod(1<<200, 100)
'16069380442589902755419620923411626025222029937827928353013.76'

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Quick poll: gmean or geometric_mean

[alister]

On Tue, 12 Jul 2016 18:42:44 -0700, Lawrence D’Oliveiro wrote:

> On Wednesday, July 13, 2016 at 10:58:14 AM UTC+12, alister wrote:
> 
>> a US gallon is smaller than an Imperial Gallon a US Mile is shorter
>> than an Imperial mile and probably most importantly (because it means
>> they keep serving me short measures) a US pint is smaller than an
>> Imperial Pint
> 
> I thought everything was bigger in the USA...



well the us fluid ounce is bigger but the US pint is only 16 oz.

that is why they keep giving me short measures unless I go to the correct 
places (The Pub in the Montecarlo Las Vegas offers both sizes :-) ) 

-- 
The more you complain, the longer God lets you live.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Were is a great place to Share your finished projects?

[Rustom Mody]

On Wednesday, July 13, 2016 at 10:42:01 AM UTC+5:30, Chris Angelico wrote:
> On Wed, Jul 13, 2016 at 2:42 PM, Ben Finney  wrote:
> > Chris Angelico writes:
> >
> >> On Wed, Jul 13, 2016 at 11:28 AM, Ben Finney  wrote:
> >> > Pull requests. Code review. Issues. Integration with other services.
> >> > All the social information around all of those interactions, and
> >> > more.
> >> >
> >> > If *any* of that is valuable, then yes it's important that it not be
> >> > locked to any one vendor.
> >>
> >> Exactly how important? Not so important as to stop slabs of Python
> >> from migrating to GitHub, including its pull request system.
> >
> > I maintain that it is important enough to stop that.
> >
> > The migration happened anyway, because not everyone is convinced of the
> > importance of avoiding vendor lock-in of valuable data, over criteria
> > such as “this person happens to like Vendor-locked Solution Foo”.
> >
> 
> Fine. You're welcome to take a 100% philosophical stance; I applaud
> you for it. (I understand Richard Stallman is so adamant about not
> using *any* non-free code - software or firmware - that he restricts
> himself to a tiny selection of laptops that have free BIOSes.)
> Personally, I believe practicality beats purity in computing
> philosophy as well as API design, and I'll happily let GitHub carry my
> software. What's the worst that can happen? I have to switch to
> somewhere else, and I lose the issue tracker and pull requests. In the
> case of CPython, they wouldn't even be lost - they're (to be) backed
> up. In the meantime, I'm on a well-polished platform with a large
> number of users. The same cannot be said for *many* other hosts, even
> if they do use exclusively free software.
> 
> ChrisA

Speaking of notable figure(heads) its good to compare Stallman (rms) and
Torvalds.

rms started working on the gnu-system before Torvalds
He did more work on that
He was (and likely is) a more capable programmer

Note further that Torvalds was told off by prof. Tanenbaum for his poor quality
unimaginative approach to Linux

Torvalds still gets the Lion's share of the credit – how many people say
“GNU-Linux distros” rather than just plain “Linux”?

I’d say this is directly related to his choosing practicality over purity
He didn’t change the obsolete (so-called) Unix API
He didn’t redesign the OS along the lines fashionable to guys like Tanenbaum

He just found himself at the right place at the right time — holding a 
protection capable home PC. And beat IBM and Microsoft at producing a kernel 
for that.

No I am not saying that the fears of Ben and Steven are unfounded
Just that we may have other battles to fight

And other heroes to cheer, eg
http://www.trueactivist.com/muslim-man-hugs-isis-suicide-bomber-saves-hundreds-of-lives-in-iraq/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Jussi Piitulainen]

Dennis Lee Bieber writes:

> On Wed, 13 Jul 2016 00:21:17 -0600, Ian Kelly 
> declaimed the following:
>
>> What if I've been doing my math with fixed-point integers (because I
>> don't know about or just don't like decimals), and now I want to
>> format them for output? Is this just wrong?
>>
>>'{:.2f}'.format(int_value / 100)
>>
>
>   Ugh... After using integers to keep accuracy in the LSB, you
> know toss it out the window by converting to a float which may have an
> inexact representation.
>
>   Presuming you kept track of the decimal place during all those
> integer operations, format as an integer, then split it at the decimal
> and insert a "." at the spot.

Of course floats fail (for this task) when the number exceeds their
integer range, but what would be a number within that range, preferably
well within that range, where they also fail? I didn't find any.

I tried to find one using the following code. First I found cases where
the output was different, but every single time (!) it was a bug in the
"safer" routine. Dismiss that as my incompetence, the fact remains that
the "dangerous" floating-point variant was never wrong at all while the
erroneous outputs from my "safer" formatters were off by an order of
magnitude. Floating point errors would be in the digits that matter
least.

No. The bugs were not in the regex. I was unsure of combining *? with
{1,2} that way - it never failed. I wasn't any surer of the non-regex
code - it kept failing.

import re, random

components = re.compile(r'(-?)(\d*?)(\d{1,2})')
def safer(x):
sign, whole, decimals = components.fullmatch(str(x)).groups()
return '{}{:>01}.{:>02}'.format(sign, whole, decimals)

def dangerouser(x):
return '{:.2f}'.format(x/100)

for n in random.sample(range(-90,91), 100):
x, y = safer(n), dangerouser(n)
if x == y: continue
print('differ:', n, x, y)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Packaging multiple wheels in the same package

[Chris Angelico]

On Wed, Jul 13, 2016 at 10:54 PM, Nir Cohen  wrote:
> On Thursday, July 7, 2016 at 7:47:22 AM UTC+3, Nir Cohen wrote:
>> On Wednesday, July 6, 2016 at 10:09:01 PM UTC+3, Ethan Furman wrote:
>> > Sounds like a great idea!
>> >
>> > Once you have your feed-back from here you'll want to take your PEP over
>> > to the dist-utils sig:
>> >
>> > https://mail.python.org/mailman/listinfo/distutils-sig
>> >
>> > --
>> > ~Ethan~
>>
>> Happy to hear :)
>>
>> btw, pull requests are certainly welcome to make whichever changes required 
>> to make Wagon PEP-worthy.
>
> Sorry to bump this up.. but I'm not sure exactly how I should go about 
> getting as much feedback as possible on this. Any suggestions?

Well a lot of the people here might *use* wheels, but a relatively
small proportion *create* them. (I'm not big on creating packages -
the only PyPI-published module of mine is a tiny pure-Python one, so
it's about as simple as it gets. And it's not even actively maintained
any more.) Ethan suggested hopping over to distutils-sig - have you
done that? That would be the next step, if you haven't.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Jussi Piitulainen]

Chris Angelico writes:

> On Wed, Jul 13, 2016 at 9:46 PM, Dennis Lee Bieber
>  wrote:
>> On Wed, 13 Jul 2016 00:21:17 -0600, Ian Kelly 
>> declaimed the following:
>>
>>> What if I've been doing my math with fixed-point integers (because I
>>> don't know about or just don't like decimals), and now I want to
>>> format them for output? Is this just wrong?
>>>
>>>'{:.2f}'.format(int_value / 100)
>>>
>>
>> Ugh... After using integers to keep accuracy in the LSB, you
>> know toss it out the window by converting to a float which may have
>> an inexact representation.
>>
>> Presuming you kept track of the decimal place during all
>> those integer operations, format as an integer, then split it at the
>> decimal and insert a "." at the spot.
>
> Or just use divmod:
>
 "%d.%02d" % divmod(1<<200, 100)
> '16069380442589902755419620923411626025222029937827928353013.76'

I'm not quite ready to blame floating point for this difference yet:

>>> "%d.%02d" % divmod(-1,100)
'-1.99'
>>> "%.2f" % (-1/100)
'-0.01'
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[Steven D'Aprano]

On Wed, 13 Jul 2016 07:46 pm, jonas.thornv...@gmail.com wrote:

> It is not that the data is not compressible 

Yes it is.

Until you explain how you can *reversibly* pack 10**100 inputs into 10**6
outputs without loss of information, all your explanations about "folding"
and polynomials and structure is just cheap talk.



-- 
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

[Chris Angelico]

On Wed, Jul 13, 2016 at 11:16 PM, Jussi Piitulainen
 wrote:
>> Or just use divmod:
>>
> "%d.%02d" % divmod(1<<200, 100)
>> '16069380442589902755419620923411626025222029937827928353013.76'
>
> I'm not quite ready to blame floating point for this difference yet:
>
 "%d.%02d" % divmod(-1,100)
> '-1.99'
 "%.2f" % (-1/100)
> '-0.01'

E, forgot about that :D Negative numbers and modulo *always* trip
me up, because different languages have different rules. I inevitably
have to go check the docos.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Antoon Pardon]

Op 13-07-16 om 10:49 schreef Steven D'Aprano:
> On Wednesday 13 July 2016 17:05, Lawrence D’Oliveiro wrote:
>
>> On Wednesday, July 13, 2016 at 6:22:31 PM UTC+12, Ian wrote:
>>
>>> I never claimed it's not useful. I don't really have a problem with
>>> format supporting it, either. But if it does, then don't call it
>>> "precision".
>> Like it or not, that is the accepted term, as used in the printf(3) man page.
>>
>> Feel free not to use common accepted terms if you don’t want. You can use
>> words to mean whatever you avocado, but don’t expect other people to carrot.
> +1 QOTW

But as far as I know, "significant digits" is not the accepted term for the
width of the representation when you print a number with added zeroes in front 
of it.

So when we start we a term like "precision" and people jump from that to 
"significant
digits", maybe we should consider how confusing the common accepted term can be.

-- 
Antoon


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Jussi Piitulainen]

Chris Angelico writes:

> On Wed, Jul 13, 2016 at 11:16 PM, Jussi Piitulainen wrote:
>>> Or just use divmod:
>>>
>> "%d.%02d" % divmod(1<<200, 100)
>>> '16069380442589902755419620923411626025222029937827928353013.76'
>>
>> I'm not quite ready to blame floating point for this difference yet:
>>
> "%d.%02d" % divmod(-1,100)
>> '-1.99'
> "%.2f" % (-1/100)
>> '-0.01'
>
> E, forgot about that :D Negative numbers and modulo *always* trip
> me up, because different languages have different rules. I inevitably
> have to go check the docos.

Julia's "Euclidean division" (div, rem, divrem) would result in '0.-1'
above :) while fld, mod, fldmod (floored or floor or flooring division)
would be the same as Python's //, %, divmod.

Python 3.4.3 help text for divmod says it returns ((x-x%y)/y, x%y) but
that's not quite correct, because type. Probably // is intended.

There are easily half a dozen different integer divisions rounding
towards or away from zero or up or down or to nearest integer with
different ways of breaking ties and matching the sign of dividend or
divisor, and a couple of other details, yet I'm not sure if any of them
alone would do the job at hand :) Leave it for someone smarter.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Chris Angelico]

On Thu, Jul 14, 2016 at 12:23 AM, Jussi Piitulainen
 wrote:
> Python 3.4.3 help text for divmod says it returns ((x-x%y)/y, x%y) but
> that's not quite correct, because type. Probably // is intended.

Starting with 3.5, it says it returns the tuple (x//y, x%y).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Packaging multiple wheels in the same package

[Ethan Furman]

On 07/13/2016 05:54 AM, Nir Cohen wrote:

On Thursday, July 7, 2016 at 7:47:22 AM UTC+3, Nir Cohen wrote:

On Wednesday, July 6, 2016 at 10:09:01 PM UTC+3, Ethan Furman wrote:

On 07/06/2016 11:43 AM, Nir Cohen wrote:



We decided that we want to package sets of wheels together created or downloaded

  > by `pip wheel`, add relevant metadata, package them together into a
single archive
  > (tar.gz or zip) and use the same tool which packs them up to install
them later on,
  > on the destination hosts.


We came up with a tool (http://github.com/cloudify-cosmo/wagon) to do just that

  > and that's what we currently use to create and install our plugins.



Sorry to bump this up.. but I'm not sure exactly how I should go about getting 
as much feedback as possible on this. Any suggestions?


You could try Python-Ideas -- plenty of debate happens on that list. ;)

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Django Tastypie Vs. Djaogn Rest Framework

[justin walters]

Hi guys and gals.

I've been building a new web application with my business partner. We're
using Django and postreSQL. We needed a restful API as we wanted the back
end to be completely decoupled from the front end. We ended up going with
Tastypie over DRF due to the former being seemingly less complex and easier
to get rolling. I've used DRF in the past and found it to have somewhat of
a steeper learning curve compared to Tastypie. The way tastypie has you
define resources seems a lot more intuitive to me than the way DRF does so.

Despite my experience, it seems like DRF is by far the more popular choice
for new applications. I was wondering if anyone could offer some insights
into why this is the case. Does DRF offer more highly optimized queries?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Touch screen development in Python

[Laurent Pointal]

Jahn wrote:

> I was thinking about Python touch screen applications for industrial
> boards( computers).
> If I have a touch screen  with that industrial board, what I must have
> installed to be able to
> write  touch screen applications in Python?

If you go with Kivy (its built for multitouch graphical interactive 
applications, can work on Windows, Linux, MacOSX, Android), see the 
following page for requirements:

https://kivy.org/docs/installation/installation.html

And learning how to use it (see examples).

https://kivy.org/docs/examples/gallery.html

Really, give it a try, even on your mouse controlled interface.

A+
Laurent.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Compression of random binary data

[Michael Torrie]

On 07/13/2016 03:46 AM, jonas.thornv...@gmail.com wrote:
> It is not that the data is not compressible i just need more chunks
> or random data, it is the footprint of the algorithm that has a
> certain it is a structure afterall albeit richer in interpretation
> than the numerical field.

Err, no, that does not apply to "random."  If the data is truly random
then it does not matter whether you have 5 bytes or 5 GB.  There is no
pattern to discern, and having more chunks of random data won't make it
possible to compress.

> You exchange size for computational complexity, but that may be true
> for any compression algorithm.

People are taking issue with your claim that you can compress random
data.  Clearly you cannot, by your own admission about requiring more
chunks of data (see above), and also by the irrefutable logical
principles Steven D'Aprano layed out.

Probably time to mute this thread. It's not related to Python.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Touch screen development in Python

[Jahn]

I would like to learn more how to write python based touch application 
for embedded system but  I do not know what conditions a touch screen must have 
so that it 
will response to touch.
Does anyone know?



> On 11.07.2016 19:21, Jahn wrote:
> > Does anyone use Python for  developping  applications that  work with a 
> > touch screen?
> 
> Yes.
> 
> 
> You should probably specify the platform and the type of applications 
> that you're interested in.
> 
> Mobiles (Android, iOS, Sailfish OS)? Windows 10 Tablets? Ubuntu Touch? 
> Embedded systems?
> 
> 
> Regards,
> 
> Dietmar
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Compression of random binary data

[Grant Edwards]

On 2016-07-13, Michael Torrie  wrote:
> On 07/13/2016 03:46 AM, jonas.thornv...@gmail.com wrote:

>> It is not that the data is not compressible i just need more chunks
>> or random data, it is the footprint of the algorithm that has a
>> certain it is a structure afterall albeit richer in interpretation
>> than the numerical field.

Well, thanks for that.  Not only was it authentic frontier
gibberish...

> Err, no, that does not apply to "random."  If the data is truly
> random then it does not matter whether you have 5 bytes or 5 GB.
> There is no pattern to discern, and having more chunks of random
> data won't make it possible to compress.

You might as well be arguing with Ludwig Plutonium.

-- 
Grant Edwards   grant.b.edwardsYow! I wonder if I should
  at   put myself in ESCROW!!
  gmail.com

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Compression of random binary data

[Marko Rauhamaa]

Michael Torrie :
> If the data is truly random then it does not matter whether you have 5
> bytes or 5 GB. There is no pattern to discern, and having more chunks
> of random data won't make it possible to compress.

That's true if "truly random" means "evenly distributed". You might have
genuine random numbers with some other distribution, for example
Gaussian: https://www.random.org/gaussian-distributions/>. Such
sequences of random numbers may well be compressible.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Python Byte Code Hacking

[Vijay Kumar]

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.

I was hoping to do a talk at a regional Python conference along these lines, so 
thought it might be a good idea to get suggestions and feedback, from the 
community.

Regards,
Vijay
--
https://mail.python.org/mailman/listinfo/python-list

problem writing excel sheet using python

[vineeth menneni]

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

Re: problem writing excel sheet using python

[Chris Angelico]

On Thu, Jul 14, 2016 at 7:29 AM, 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.
>

You can probably build it progressively, row by row. That way, you
shouldn't need to keep everything in memory at once. But beyond that,
I can't say without seeing your code.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Touch screen development in Python

[Michael Torrie]

On 07/13/2016 01:33 PM, Jahn wrote:
> I would like to learn more how to write python based touch application 
> for embedded system but  I do not know what conditions a touch screen must 
> have so that it 
> will response to touch.
> Does anyone know?

These days GUI toolkits such as GTK+ or Qt provide convenient methods
for interacting with touch displays including touch, dragging, gestures
(pinch to zoom), multi-touch, etc.

In its simplest form GUIs on touch screens are identical to GUIs with a
mouse.  Normal button widgets work great with fingers for example.  Even
slider adjusters work pretty much the same with a finger and with the
mouse.

More complicated things like pinch to zoom and multi-touch require a bit
more help from the toolkit.

As Deitmar said, you will have to get a lot more specific in your questions.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Lawrence D’Oliveiro]

On Wednesday, July 13, 2016 at 6:22:31 PM UTC+12, Ian wrote:

> ... don't call it "precision".

How about “mantissa length”, then. That sufficiently neutral for you?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Were is a great place to Share your finished projects?

[Lawrence D’Oliveiro]

On Thursday, July 14, 2016 at 1:03:30 AM UTC+12, Rustom Mody wrote:
>
> Note further that Torvalds was told off by prof. Tanenbaum for his poor
> quality unimaginative approach to Linux

And today, Prof Tanenbaum is struggling to find a little niche where his Minix 
product can be of relevance, while the entire computing world is converging 
around Linux.

Who was the “poor quality unimaginative” one, again?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: problem writing excel sheet using python

[Lawrence D’Oliveiro]

On Thursday, July 14, 2016 at 9:29:23 AM UTC+12, vineeth menneni wrote:
>
> .. I am finding it difficult to create a excel sheet using openpyxl or
> xlsxwriter.

How about writing ODF using odfpy  instead? 
Microsoft Office is supposed to be ISO-26300-compliant, isn’t it?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] Compression of random binary data

[Tim Delaney]

On 14 July 2016 at 05:35, Marko Rauhamaa  wrote:

> Michael Torrie :
> > If the data is truly random then it does not matter whether you have 5
> > bytes or 5 GB. There is no pattern to discern, and having more chunks
> > of random data won't make it possible to compress.
>
> That's true if "truly random" means "evenly distributed". You might have
> genuine random numbers with some other distribution, for example
> Gaussian: https://www.random.org/gaussian-distributions/>. Such
> sequences of random numbers may well be compressible.
>

No one is saying that *all* random data is incompressible - in fact, some
random samples are *very* compressible. A single sample of random data
might look very much like the text of "A Midsummer Night's Dream"
(especially if your method of choosing the random sample was to pick a book
off a library shelf).

But unless otherwise qualified, a claim of being able to compress random
data is taken to mean any and all sets of random data.

Anyway, that's going to be my only contribution to this thread.

Tim Delaney
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Clean Singleton Docstrings

[Lawrence D’Oliveiro]

On Friday, July 8, 2016 at 7:38:56 PM UTC+12, Peter Otten wrote:

> There is a test
> 
> if not object:
> raise ImportError('no Python documentation found for %r' % thing)
> 
> in the pydoc module. So all you need is to ensure that your Registry 
> evaluates to True in a boolean context, e. g. by putting something into it: 

And there are still those who think that Python’s lax acceptance of non-boolean 
values as booleans is a good idea...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Clean Singleton Docstrings

[Peter Otten]

Lawrence D’Oliveiro wrote:

> On Friday, July 8, 2016 at 7:38:56 PM UTC+12, Peter Otten wrote:
> 
>> There is a test
>> 
>> if not object:
>> raise ImportError('no Python documentation found for %r' % thing)
>> 
>> in the pydoc module. So all you need is to ensure that your Registry
>> evaluates to True in a boolean context, e. g. by putting something into
>> it:
> 
> And there are still those who think that Python’s lax acceptance of
> non-boolean values as booleans is a good idea...

I don't think this particular problem serves as an argument for stricter 
handling of boolean expressions because the fix

if object is not None: ...

is not completely correct, either:

$ cat demo.py
no = False
yes = True
maybe = None
$ pydoc3.4 demo.yes | head -n3
Help on bool in demo object:

demo.yes = class bool(int)
$ pydoc3.4 demo.no | head -n3
no Python documentation found for 'demo.no'

$ pydoc3.5 demo.no | head -n3
Help on bool in demo object:

demo.no = class bool(int)
$ pydoc3.5 demo.maybe | head -n3
No Python documentation found for 'demo.maybe'.
Use help() to get the interactive help utility.
Use help(str) for help on the str class.

Better would be to let the locate() function raise an exception along these 
lines:

   for part in parts[n:]:
try:
object = getattr(object, part)
except AttributeError:
# return None
raise ImportError("Name ... not found in module ...")

PS: Do the new hints
"""
Use help() to get the interactive help utility.
Use help(str) for help on the str class.
"""
make any sense? Not to me, at this time of the day...

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Byte Code Hacking

[Ian Kelly]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Clean Singleton Docstrings

[Ian Kelly]

On Wed, Jul 13, 2016 at 5:54 PM, Peter Otten <__pete...@web.de> wrote:
> Lawrence D’Oliveiro wrote:
>
>> On Friday, July 8, 2016 at 7:38:56 PM UTC+12, Peter Otten wrote:
>>
>>> There is a test
>>>
>>> if not object:
>>> raise ImportError('no Python documentation found for %r' % thing)
>>>
>>> in the pydoc module. So all you need is to ensure that your Registry
>>> evaluates to True in a boolean context, e. g. by putting something into
>>> it:
>>
>> And there are still those who think that Python’s lax acceptance of
>> non-boolean values as booleans is a good idea...
>
> I don't think this particular problem serves as an argument for stricter
> handling of boolean expressions because the fix
>
> if object is not None: ...
>
> is not completely correct, either:

A better fix would be to have the locate function raise an exception
if the thing is not found instead of returning None.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: problem writing excel sheet using python

[vineeth menneni]

The belwo is the code, I have also tried writing it row by row with xlsxwrites 
passing argument constant_memory:True. I donot know if my looping code is 
ineffective.   

for req_param in request.GET.get("Req-Tables").split(","):
sheet_names.append(req_param)
title.append(req_param)
report_data=db_exec_query( param_table_map[req_param])
sheet_names[key]=wb.active
if key!=0:
sheet_names[key]=wb.create_sheet(title= (title[key][:15] ) if 
title[key] > 15 else title[key])
 req_param, sys.getsizeof(report_data))
count= 0
for r in report_data:
try:
sheet_names[key].append(r)
except:
sheet_names[key].append(str(c).decode('cp1252') for c in r)
key=key+1

wb.save(response)




On Wednesday, July 13, 2016 at 2:41:43 PM UTC-7, Chris Angelico wrote:
> On Thu, Jul 14, 2016 at 7:29 AM, 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.
> >
> 
> You can probably build it progressively, row by row. That way, you
> shouldn't need to keep everything in memory at once. But beyond that,
> I can't say without seeing your code.
> 
> ChrisA

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Wed, Jul 13, 2016 at 4:24 PM, Lawrence D’Oliveiro
 wrote:
> On Wednesday, July 13, 2016 at 6:22:31 PM UTC+12, Ian wrote:
>
>> ... don't call it "precision".
>
> How about “mantissa length”, then. That sufficiently neutral for you?

That makes even less sense for integers.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[MRAB]

On 2016-07-14 01:45, Ian Kelly wrote:

On Wed, Jul 13, 2016 at 4:24 PM, Lawrence D’Oliveiro
 wrote:

On Wednesday, July 13, 2016 at 6:22:31 PM UTC+12, Ian wrote:


... don't call it "precision".


How about “mantissa length”, then. That sufficiently neutral for you?


That makes even less sense for integers.


Perhaps "precision or whatever"? :-)

--
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Lawrence D’Oliveiro]

On Thursday, July 14, 2016 at 12:46:26 PM UTC+12, Ian wrote:
> On Wed, Jul 13, 2016 at 4:24 PM, Lawrence D’Oliveiro wrote:
>> On Wednesday, July 13, 2016 at 6:22:31 PM UTC+12, Ian wrote:
>>
>>> ... don't call it "precision".
>>
>> How about “mantissa length”, then. That sufficiently neutral for you?
> 
> That makes even less sense for integers.

Why?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Were is a great place to Share your finished projects?

[Michael Torrie]

On 07/13/2016 01:00 AM, Chris Angelico wrote:
> On Wed, Jul 13, 2016 at 4:44 PM, Steven D'Aprano
>  wrote:
>> Even if Github was 100% open source with no proprietary extensions, and the
>> *technical* cost of leaving was low, the single-network effect would still 
>> lock
>> you in, which leaves you (to some degree) at the mercy of Github's 
>> management.
>> Don't like the fact that they run their servers on electricity made from
>> burning puppies and the tears of little children? Too bad, what are you going
>> to do, move your project to some backwater VCS where nobody ever goes? You
>> might as well be on AOL for all anyone will ever find your project.
> 
> So what're you going to do? Move *now* to some backwater where nobody
> ever goes, just in case GitHub ever turns evil?

No, you just run git as it was designed to be used.  In a completely
decentralized fashion.  If Github had honored this aspect of git,
there'd be no problem.  A repo on GitHub would be just one of many
publicly-facing git repos.  But by refusing to allow federated pull
requests, GitHub has most definitely created lock-in.

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.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Were is a great place to Share your finished projects?

[Paul Rubin]

Michael Torrie  writes:
> So I can understand the allure of GitHub.  It's shiny and free-ish.

Savannah.nongnu.org is a nice free host for free software projects.  I
suppose it's less shiny than Github.  On the other hand, Github is
written in Ruby--what self-respecting Pythonista would stand for that?! ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Wed, Jul 13, 2016 at 9:39 PM, Lawrence D’Oliveiro
 wrote:
> On Thursday, July 14, 2016 at 12:46:26 PM UTC+12, Ian wrote:
>> On Wed, Jul 13, 2016 at 4:24 PM, Lawrence D’Oliveiro wrote:
>>> On Wednesday, July 13, 2016 at 6:22:31 PM UTC+12, Ian wrote:
>>>
 ... don't call it "precision".
>>>
>>> How about “mantissa length”, then. That sufficiently neutral for you?
>>
>> That makes even less sense for integers.
>
> Why?

Because integers don't have a mantissa.

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.

Back to naming, I think the best you could do would just be something
utterly generic like "formatted size". It doesn't help that in some
cases it represents a minimum size and in other cases a maximum, so
you can't even characterize it with that.
-- 
https://mail.python.org/mailman/listinfo/python-list