[RELEASE] Python 3.6.0a3 is now available

[Ned Deily]

On behalf of the Python development community and the Python 3.6 release
team, I'm happy to announce the availability of Python 3.6.0a3.
3.6.0a3 is the third of four planned alpha releases of Python 3.6,
the next major release of Python.  During the alpha phase, Python 3.6
remains under heavy development: additional features will be added
and existing features may be modified or deleted.  Please keep in mind
that this is a preview release and its use is not recommended for
production environments.

You can find Python 3.6.0a3 here:

https://www.python.org/downloads/release/python-360a3/ 

The next release of Python 3.6 will be 3.6.0a4, currently scheduled for
2016-08-15.

--Ned

--
  Ned Deily
  n...@python.org -- []

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

[issue27491] Errors when building with UNICODE character set

[Minmin Gong]

New submission from Minmin Gong:

Switch the pythoncore's character set to UNICODE, some compile errors about 
Windows APIs show up. A patch is attached to fix this.

--
components: Windows
files: 0001-Fix-building-with-UNICODE-character-set.patch
keywords: patch
messages: 270228
nosy: Minmin.Gong, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Errors when building with UNICODE character set
type: compile error
versions: Python 3.5
Added file: 
http://bugs.python.org/file43696/0001-Fix-building-with-UNICODE-character-set.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27083] PYTHONCASEOK is ignored on Windows

[Brian Herman]

Brian Herman added the comment:

In python 3.6 from hg it has been fixed.

>>> glob.glob('*.py')
['setup.py', 'test.py']
>>> import test
>>> test.__file__
'C:\\Users\\brian\\Desktop\\cpython\\test.py'
>>>

--
nosy: +Brian.Herman

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats)

[Chris Angelico]

On Tue, Jul 12, 2016 at 2:19 PM, Steven D'Aprano  wrote:
> On Tue, 12 Jul 2016 07:51 am, Chris Angelico wrote:
>
>> say, 2,147
>> millimeters, with a precision of four significant digits
>
>
> How do you represent 1 mm to a precision of four significant digits, in such
> a way that it is distinguished from 1 mm to one significant digit, and 1 mm
> to a precision of four decimal places?
>
> 0001
> 1
> 1.

Exactly my point. Granted, I mucked up my example (subtraction doesn't
maintain sig figs - apologies, my bad), but there are other ways to
end up with numbers close to zero with more sig figs than nonzero
digits.

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

[issue14977] mailcap does not respect precedence in the presence of wildcards

[Michael Lazar]

Michael Lazar added the comment:

Submitting an updated patch; simplified the implementation and updated 
test_mailcap.py

--
Added file: http://bugs.python.org/file43695/mailcap_v2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Touch screen development in Python

[Paul Rubin]

"Jahn"  writes:
> Does anyone use Python for developping applications that work with a
> touch screen?

I've done it on a system where the touch screen events were treated the
same way as mouse events.  Coding works out about the same way.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats)

[Steven D'Aprano]

On Tue, 12 Jul 2016 07:51 am, Chris Angelico wrote:

> say, 2,147
> millimeters, with a precision of four significant digits


How do you represent 1 mm to a precision of four significant digits, in such
a way that it is distinguished from 1 mm to one significant digit, and 1 mm
to a precision of four decimal places?

0001
1
1.



-- 
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: What is precision of a number representation?

[Terry Reedy]

On 7/11/2016 6:17 PM, Ethan Furman wrote:

On 07/11/2016 02:51 PM, Chris Angelico wrote:



This is why it's important to be able to record precisions of
arbitrary numbers. If I then measure the width of this corridor with a
laser, I could get an extremely precise answer - say, 2,147
millimeters, with a precision of four significant digits, and
excellent accuracy. But if I multiply those numbers together to
establish the floor area of the corridor, the result does NOT have
four significant figures. It would be 64 square meters (not 64.41),
and the accuracy would be pretty low (effectively, the *in*accuracies
of both measurements get combined). But on the other hand, if you want
to know whether your new fridge will fit, you could measure it with
the same laser and come up with a figure of 1,973 mm (four sig fig),
which would mean your clearance is 174mm (four sig fig). How do you
record this? Is it 174.0? 0174? "174 with four significant figures"?


174.0,


A common fallacy.  There are only 3 significant figures because one, the 
first, was cancelled by subtracting close numbers.  The same is true of 
adding numbers of opposite signs.


--
Terry Jan Reedy

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

Re: What is precision of a number representation?

[Terry Reedy]

On 7/11/2016 5:51 PM, Chris Angelico wrote:


This is why it's important to be able to record precisions of
arbitrary numbers. If I then measure the width of this corridor with a
laser, I could get an extremely precise answer - say, 2,147
millimeters, with a precision of four significant digits, and
excellent accuracy. But if I multiply those numbers together to
establish the floor area of the corridor, the result does NOT have
four significant figures. It would be 64 square meters (not 64.41),
and the accuracy would be pretty low (effectively, the *in*accuracies
of both measurements get combined). But on the other hand, if you want
to know whether your new fridge will fit, you could measure it with
the same laser and come up with a figure of 1,973 mm (four sig fig),
which would mean your clearance is 174mm (four sig fig).


Wrong as to the last point. 2147 - 1973 = 174 has only 3 sig. figures. 
2147 - 2144 = 3 has 1 significant figure.  Subtraction of nearly equal 
numbers can cancel sig. figures.


> How do you

record this? Is it 174.0? 0174? "174 with four significant figures"?


None of these.

--
Terry Jan Reedy

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

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

[Nick Coghlan]

Nick Coghlan added the comment:

Since this worked in 3.5.1, and fails in 3.5.2, I think it's reasonable to 
consider if it makes sense to find a way to make it work again in 3.5.3 (and 
then decide separately whether or not we want to preserve the capability in 
3.6.0).

Specifically, restoring the old behaviour would mean that:

1. *If* the -m target module already exists in sys.modules after importing the 
parent module; and
2. The already imported target module doesn't have a __spec__ attribute; then
3. Ignore that already imported artifact when figuring out what to run as 
__main__

However, the problem with doing that is that this *is* an instance of code that 
falls into the double-import trap: 
http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html#executing-the-main-module-twice

Even in 3.5.1, the affected module is getting executed twice - once from the 
package's __init__.py, and once via the "-m" switch. For cases that *don't* 
overwrite the module in sys.modules, a solution that resolves the issue in a 
backwards and forwards compatible way is to split the module being executed via 
-m as follows:

* Move the pieces needed by mypkg.__init__ into a "mypkg._mymain_support" module
* In that module, set "__name__ = 'mypkg.mymain'" to preserve pickle 
compatibility and docs introspection
* Change both "mypkg.__init__" and "mypkg.mymain" to import the shared 
components from the "mypkg._mymain_support" module

However, you still run into a problem with figuring out when the replacement 
module should be written into sys.modules - if that stays in "mypkg.mymain" it 
will no longer get done as a side effect of importing "mypkg", while if it 
moves into "mypkg._mymain_support", you'll still run into the problem reported 
here in 3.5.2

--
nosy: +brett.cannon, eric.snow

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16858] tarfile silently hides errors

[Martin Panter]

Changes by Martin Panter :


--
Removed message: http://bugs.python.org/msg265966

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: What is precision of a number representation?

[Ben Finney]

Ethan Furman  writes:

> On 07/11/2016 01:56 PM, Ben Finney wrote:
>
> > Precision is not a property of the number. It is a property of the
> > *representation* of that number.
> >
> > The representation “1×10²” has a precision of one digit.
> > The representation “100” has a precision of three digits.
> > The representation “00100” has a precision of five digits.
> > The representation “100.00” also has a precision of five digits.
>
> […] you haven't explained how 00100 is more precise than 100.

I haven't made any claim about “more precise” in the above.

But if you want such claims, here are comparable representations in
increasing order of precision:

* “0 ×10²” has one digit of precision.
* “0.0 ×10²” has two digits of precison.
* “0.01 ×10²” has three digits of precision.
* “0.010 ×10²” has four digits of precision.
* “0.0100 ×10²” has five digits of precision.
* “0.01000 ×10²” has six digits of precision.

Again, these might all be representations of the same number or of
different numbers; the representation claims only to represent a number
within a range of tolerance.


In decimal notation, some of the above can't be written with the same
precision. I could invent a representation — e.g. show “?” as a
place-holder for a digit not within the precision level. In that system,
the equivalent representations would be:

* “0”
* “00???”
* “001??”
* “0010?”
* “00100”
* “00100.0”

Each of these claims to represent a quantity beginning at the
ten-thousands place, with increasing levels of precision in the claim.

So the comparison that invites is to show where the range of tolerance
for the representation ends. The fewer digits of precision, the less
precise the representation claims to be.

-- 
 \  “I find the whole business of religion profoundly interesting. |
  `\ But it does mystify me that otherwise intelligent people take |
_o__)it seriously.” —Douglas Adams |
Ben Finney

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

Re: Curious Omission In New-Style Formats

[Steven D'Aprano]

On Tue, 12 Jul 2016 04:38 am, Ian Kelly wrote:

> In what way do the leading zeroes in "00123" add to the precision of
> the number? 00123 is the same quantity as 123 and represents no more
> precise a measurement. 

You guys... next you're going to tell me that 1.23 and 1.2300 are the same
quantity and represent no more precise a measurement :-) And keep adding
zeroes 1.23000... and claim infinite precision.

That's not now "precision" works. Its true that *mathematically* leading
zeroes don't change the number, but neither do trailing zeroes.
Nevertheless, we *interpret* them as having meaning, as indicators of the
precision of measurement in the mathematical sense.

In a moment, I'm going to attempt to justify a reasonable meaning for
leading zeroes. But that's actually not relevant. printf (and Python's %
string operator) interprets the precision field in the mathematical sense
for floats, but that's not the only sense possible. The word "precise" has
a number of meanings, including:

- exactness
- accurate
- strict conformity to a rule
- politeness and nicety
- the quality of being reproducible


For integers, printf and % interpret the so-called "precision" field of the
format string not as a measurement precision (number of decimal places),
but as the number of digits to use (which is different from the total field
width). For example:


py> "%10.8x" % 123
'  007b'

How anyone can possibly claim this makes no sense is beyond me! Is the
difference between "number of digits" and "number of decimal places" really
so hard to grok? I think not.

And it's clearly useful: with integers, particular if they represent
fixed-size byte quantities, it is very common to use leading zeroes. To a
programmer the hex values 7b, 007b and 007b have very different
meanings: the first is a byte, the second may be a short int, and the third
may be a long int.

Why shouldn't we use the "precision" field for this? It doesn't mean what
scientists mean by precision, but so what? That's not important. Scientists
don't usually have to worry about leading zeroes, but programmers do, and
its useful to distinguish between the *total* width (padded with spaces)
and the *number* width (padded with zeroes).

I think that printf and % get this right, and format() gets it wrong.


[...]
>>> If you truly wanted to format the number with a precision
>>> of 5 digits, it would look like this:
>>>
>>> 0x123.00
>>
>> Er, no, because its an integer.
> 
> Which is why if you actually want to do this, you should convert it to
> a decimal or a float first (of course, those don't support hexadecimal
> output, so if you actually want hexadecimal output *and* digits after
> the (hexa)decimal point, then I think you would just have to roll your
> own formatting at that point).

What? No no no. Didn't you even look at Lawrence's example? He doesn't want
to format the number with decimal places at all.

Converting an integer to a float just to use the precision field is just
wrong. That's like saying that "1234".upper() doesn't make sense because
digits don't have uppercase forms, and if you really want to convert "1234"
to uppercase you should spell it out in words first:

"onetwothreefour".upper()



Earlier, I said that I would attempt to give a justification for leading
zeroes in terms of measurement too. As I said, this is strictly irrelevant,
but I thought it was interesting and so I'm going to share. You can stop
reading now if you prefer.

If you measure something with a metre ruler marked in centimetres, getting
1.23 metres, that's quite different from measuring it with a ruler marked
in tenths of a millimetres and getting 1.2300. That's basic usage for
precision in terms of number of decimal places and I'm sure we all agree
about that.

Now lets go the other way. How to you distinguish between a distance
measured using an unmarked metre stick, giving us an answer of 123 metres,
versus something measured with a 10km ruler(!) with one metre markings?
Obviously with *leading* zeroes rather than trailing zeroes. If I lay out
the one metre stick 123 times, then I write the measurement as 123. If I
lay out my 10km ruler and note the position, I measure:

zero tens of kilometres;
zero kilometres;
three hundreds-of-metres;
two tens-of-metres;
three metres;

giving 00123 metres of course. Simple!

Of course, it's rare that we do that. Why would we bother to distinguish the
two situations? And who the hell has a 10km long measuring stick?

If I'm a scientist, I'll probably write them both as 123m and not care about
the size of the measuring stick, only about the smallest marking on it. At
least for measuring straight-line distances, the size of the measuring
stick generally doesn't matter.

It *does* matter for measuring curves, but paradoxically the bigger the
measuring stick (the more leading zeroes) the worse your measurement is
likely to be. This is the problem of measuring coastlines and is related to
fractal dimension. Suppose I 

subprocess: xterm -c cat, need to send data to cat and have it displayed in the xterm window

[Veek. M]

Script grabs some image data and runs imagemagick on it to extract some 
chinese. Then tesseract OCR to get the actual unicode.

I then need to get it translated which also works and then display in 
XTerm using cat.

I could cat << named_pipe but I was wondering if this was the only way?
Could I juggle fd's instead?


#!/usr/bin/python
# -*- coding: utf-8 -*-

import sys, time

import shlex
import codecs, subprocess

import goslate
from textblob.blob import TextBlob


def cmd_exec(cmd, wait=True, shell=True):
print cmd

cmd_line = shlex.split(cmd)
retobj = subprocess.Popen(cmd_line, shell, cwd='/tmp', 
stdin=subprocess.PIPE)

if wait:
retobj.wait()

return retobj

def get_text_and_process(skip=False):
if skip: return
cmd_exec('import /tmp/x.png')
cmd_exec('convert /tmp/x.png -resize 200% /tmp/x.resize.png')
cmd_exec('tesseract /tmp/x.resize.png /tmp/tao -l chi_sim')


get_text_and_process(skip=True)

fh = codecs.open('/tmp/tao.txt', encoding='utf-8')
fd = cmd_exec('xterm -en utf-8 -geometry 50x20+0+0 -e /bin/bash -c "cat 
-"', shell=False, wait=False)
fd.communicate('test\n') #how do i communicate with cat and not xterm
sys.exit() #I EXIT HERE


#This stuff doesn't run (but works) - sys.exit above
for line in fh.readlines():
try:
print >>fd.stdout, line.encode('utf-8')

blob = TextBlob(line)
print >>fd.stdout, blob.detect_language()
print >>fd.stdin, blob.translate(to='en') 
except UnicodeDecodeError, TranslatorError:
pass

fh.close()
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue13402] Document absoluteness of sys.executable

[Ned Deily]

Ned Deily added the comment:

@blarsen, OK, but if you want to pursue this, please open a new issue against 
the current versions.  This issue was closed years ago and against earlier 
versions so your comments will not get acted on.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Compression of random binary data

[Lawrence D’Oliveiro]

On Tuesday, July 12, 2016 at 5:52:27 AM UTC+12, jonas.t...@gmail.com wrote:

> What kind of statistic law or mathematical conjecture  or is it even a
> physical law is violated by compression of random binary data? 

Try compressing already-compressed data.

Does that answer your question?
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue13402] Document absoluteness of sys.executable

[Brad Larsen]

Brad Larsen added the comment:

@eryksun, you are right!  The output *is* an absolute path as far as 
`os.path.isabs` is concerned.

@ned.deily, you are right about my example --- I transcribed it wrong, and it 
should be `-c`.

The system in question is not a Mac OS system, but a Linux system with newer 
Python versions than what come with the system installed to /opt/local.  These 
are compiled from source, but without any modifications.

I'm commenting here because I'm seeing the `test_sys` test from the regression 
suite fail in a slightly modified version of Python that ships with a product.  
In particular, in Lib/test/test_sys.py around line 640, we have this:

@unittest.skipIf(sys.base_prefix != sys.prefix,
 'Test is not venv-compatible')
def test_executable(self):
# sys.executable should be absolute
self.assertEqual(os.path.abspath(sys.executable), sys.executable)

Yes, /opt/local/bin/../bin/python3.5 is an absolute path as far as 
`os.path.isabs` is concerned, but 
`os.path.abspath('/opt/local/bin/../bin/python3.5')` gives 
'/opt/local/bin/python3.5', and the test fails.  So maybe the documentation is 
fine but the test is wrong?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13402] Document absoluteness of sys.executable

[Ned Deily]

Ned Deily added the comment:

@blarsen, and there's something strange about your example.  '-m' won't work 
with a real python executable, presumably you meant '-c'.  And judging from the 
paths involved, I'm guessing you are using MacPorts on OS X.  With either 
MacPorts or any other OS X framework build, you wouldn't see results like that 
with -c.

 ../bin/python3.5 -c 'import sys; print(sys.executable)'
/opt/local/bin/python3.5
../bin/python2.7 -c 'import sys; print(sys.executable)'
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

So I'm guessing what's in ../bin/python3.7 and ../bin/python3.5 is something 
other than the normal python bootstrap binaries.

--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26081] Implement asyncio Future in C to improve performance

[INADA Naoki]

INADA Naoki added the comment:

Thanks.  I'll working on test_asyncio in next few days.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16858] tarfile silently hides errors

[Berker Peksag]

Changes by Berker Peksag :


--
Removed message: http://bugs.python.org/msg270206

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16858] tarfile silently hides errors

[Berker Peksag]

Changes by Berker Peksag :


--
Removed message: http://bugs.python.org/msg265967

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16858] tarfile silently hides errors

[Berker Peksag]

Changes by Berker Peksag :


--
Removed message: http://bugs.python.org/msg270204

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue672115] Assignment to __bases__ of direct object subclasses

[Memeplex]

Memeplex added the comment:

I understand Michael's comment http://bugs.python.org/issue672115#msg14169 but 
I'm failing to see how it's directly related to this issue: as Michael himself 
said it's even relevant for the object-subclass-object hack or for any 
hierarchy whatsoever. Is the comment warning about the entire writable-bases 
idea? It feels to me like the behavior should be consistently extended or 
consistently banned, but currently some cases work, another cases don't, and 
there seems to be no clear rationale supporting this state of affairs. Am I 
wrong?

--
nosy: +memeplex

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: What is precision of a number representation?

[Chris Angelico]

On Tue, Jul 12, 2016 at 8:17 AM, Ethan Furman  wrote:
>> This is why it's important to be able to record precisions of
>> arbitrary numbers. If I then measure the width of this corridor with a
>> laser, I could get an extremely precise answer - say, 2,147
>> millimeters, with a precision of four significant digits, and
>> excellent accuracy. But if I multiply those numbers together to
>> establish the floor area of the corridor, the result does NOT have
>> four significant figures. It would be 64 square meters (not 64.41),
>> and the accuracy would be pretty low (effectively, the *in*accuracies
>> of both measurements get combined). But on the other hand, if you want
>> to know whether your new fridge will fit, you could measure it with
>> the same laser and come up with a figure of 1,973 mm (four sig fig),
>> which would mean your clearance is 174mm (four sig fig). How do you
>> record this? Is it 174.0? 0174? "174 with four significant figures"?
>
>
> 174.0, because those last tenths of a millimeter could be very important,
> while knowledge that there are no thousands of millimeters is already
> present.
>

But I never measured it to tenths of a millimeter. The display on my
laser measurer (I don't actually have one, by the way, so all this is
complete fabrication for the sake of the example) displays integer
millimeters, with an implicit "+/- 0.5 mm".

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

[issue26988] Add AutoNumberedEnum to stdlib

[Ethan Furman]

Ethan Furman added the comment:

Here's the code.  I'll do the doc changes next.

--
keywords: +patch
Added file: http://bugs.python.org/file43694/issue26988.stoneleaf.01.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Mon, Jul 11, 2016 at 5:47 PM, Gregory Ewing
 wrote:
> Ethan Furman wrote:
>>
>> I will readily admit to not having a maths degree, and so of course to me
>> saying the integer 123 has a precision of 5, 10, or 99 digits seems like
>> hogwash to me.
>
>
> Seems to me insisting that the number after the dot be
> called "precision" in all cases is imposing a foolish
> consistency.
>
> There's a third thing that %-formats use it for as well:
> for a string it means the maximum number of characters
> to include.
>
> To my way of thinking, the format string just lets you
> specify uop to two numbers, the interpratation or wnich
> is up to toe format concerned.

The builtin types strive for consistency with each other and with
printf-style formats, but ultimately the parsing of the format spec is
entirely at the whim of the __format__ method of the type being
formatted. You could make it a Turing-complete mini-language if you
liked.

py> class Foo:
... def __format__(self, spec):
... return str(eval(spec)(self))
...
py> '{:id}'.format(Foo())
'139869336090384'
py> '{:repr}'.format(Foo())
'<__main__.Foo object at 0x7f35de17b7b8>'
py> '{:lambda x: x == 42}'.format(Foo())
'False'
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27485] urllib.splitport -- is it official or not?

[Guido van Rossum]

Guido van Rossum added the comment:

Aha. I see you are referring to this note in the 2.7 docs for urllib:

urllib also exposes certain utility functions like splittype, splithost and
others parsing URL into various components. But it is recommended to use
:mod:`urlparse` for parsing URLs rather than using these functions directly.
Python 3 does not expose these helper functions from :mod:`urllib.parse`
module.

This is somewhat ironic because those functions still exist in urllib.parse.

I've rewritten my code using your suggestions of using urllib.parse.urlparse().

Shall we just close this issue or is there still an action item? (Maybe 
actually delete those functions whose deletion has been promised so long ago, 
or at least rename them to _splitport() etc.?)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Compression of random binary data

[Michael Selik]

On Mon, Jul 11, 2016, 10:56 AM  wrote:

> What kind of statistic law or mathematical conjecture  or is it even a
> physical law is violated by compression of random binary data?
>

If you get lucky, you might be able to achieve very good compression.

> http://dilbert.com/strip/2001-10-25

Or are you asking about an algorithm that reliably compresses random data
by a fairly constant percent?

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

[issue13402] Document absoluteness of sys.executable

[Eryk Sun]

Eryk Sun added the comment:

"/opt/local/bin/../bin/python2.7" is an absolute path. 

>>> os.path.isabs('/opt/local/bin/../bin/python2.7')
True

It's not relative to the working directory.

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26608] RLock undocumented behavior in case of multiple acquire

[ahxxm]

ahxxm added the comment:

As seen from commit log, all return type are double back-quoted, this could be 
a rendering error.

I think this commit somehow makes it clear that RLock is a thread-level 
reentrant lock, some code example of suggested usage might be helpful though.

--
hgrepos: +348
nosy: +ahxxm

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Curious Omission In New-Style Formats

[Ethan Furman]

On 07/11/2016 04:47 PM, Gregory Ewing wrote:

Ethan Furman wrote:



I will readily admit to not having a maths degree, and so of course to
me saying the integer 123 has a precision of 5, 10, or 99 digits seems
like hogwash to me.


Seems to me insisting that the number after the dot be
called "precision" in all cases is imposing a foolish
consistency.


That isn't what I said.


To my way of thinking, the format string just lets you
specify up to two numbers, the interpretation or which
is up to to format concerned.


Agreed.

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

Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats)

[Chris Angelico]

On Tue, Jul 12, 2016 at 9:14 AM, Jan Coombs
 wrote:
> Thees all look good, but you may get into trouble if you trust a
> PC with them!
>
> If the language/PC uses floating point representation then it
> will assign a fixed number of bits for the fractional part, and
> this will be left aligned in all/most hardware.

PCs don't necessarily use floating point. Just check out Python's own
decimal.Decimal class, or roll your own if you need to.

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

Re: Curious Omission In New-Style Formats

[Gregory Ewing]

Ethan Furman wrote:
I will readily admit to not having a maths degree, and so of course to 
me saying the integer 123 has a precision of 5, 10, or 99 digits seems 
like hogwash to me.


Seems to me insisting that the number after the dot be
called "precision" in all cases is imposing a foolish
consistency.

There's a third thing that %-formats use it for as well:
for a string it means the maximum number of characters
to include.

To my way of thinking, the format string just lets you
specify uop to two numbers, the interpratation or wnich
is up to toe format concerned.

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

[issue27485] urllib.splitport -- is it official or not?

[Martin Panter]

Martin Panter added the comment:

Previous discussion: Issue 1722, Issue 11009.

In Python 2, most of the split- functions _have_ been in urllib.__all__ since 
revision 5d68afc5227c (2.1). Also, since revision c3656dca65e7 (Issue 1722, 
2.7.4), the RST documentation does mention that at least some of them are 
deprecated in favour of the “urlparse” module. However there are no index 
entries, and splitport() is not mentioned by name.

In Python 3, these functions wandered into urllib.parse. There is no RST 
documentation, and the functions are not in __all__ (which was added for Issue 
13287 in 3.3).

I think you can use the documented urllib.parse API instead of splitport(), but 
it is borderline unwieldy:

>>> netloc = "[::1]:80"
>>> urllib.parse.splitport(netloc)  # [Brackets] kept!
('[::1]', '80')
>>> split = urlsplit("//" + netloc); (split.hostname, split.port)
('::1', 80)
>>> split = SplitResult("", netloc, path="", query="", fragment=""); 
>>> (split.hostname, split.port)
('::1', 80)

I opened Issue 23416 with a suggestion that would make SplitResult a bit 
simpler to use here. But maybe it makes the implementation too complicated.

I don’t think the non-split-names (Quoter, etc) are in much doubt. They were 
never in __all__.

--
nosy: +martin.panter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Curious Omission In New-Style Formats

[Gregory Ewing]

I seem to remember Guido stating once that a design principle of
the new formatting system was for the part after the colon to
be the same as what you would put in an equivalent %-format,
to make it easy for people to switch between them.

If that principle still stands, then this would seem to be
a bug.

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

Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats)

[Jan Coombs]

On Tue, 12 Jul 2016 07:51:23 +1000
Chris Angelico  wrote:

[snip]
> 
> Yep. Precision is also a property of a measurement, the same
> way that a unit is. If I pace out the length of the main
> corridor in my house, I might come up with a result of thirty
> meters. The number is "30"; the unit is "meters", the
> precision is two significant digits, and the accuracy depends
> on how good I am at pacing distance.
> 
> This is why it's important to be able to record precisions of
> arbitrary numbers. If I then measure the width of this
> corridor with a laser, I could get an extremely precise answer
> - say, 2,147 millimeters, with a precision of four significant
> digits, and excellent accuracy. But if I multiply those
> numbers together to establish the floor area of the corridor,
> the result does NOT have four significant figures. It would be
> 64 square meters (not 64.41), and the accuracy would be pretty
> low (effectively, the *in*accuracies of both measurements get
> combined). But on the other hand, if you want to know whether
> your new fridge will fit, you could measure it with the same
> laser and come up with a figure of 1,973 mm (four sig fig),
> which would mean your clearance is 174mm (four sig fig). How
> do you record this? Is it 174.0? 0174? "174 with four
> significant figures"?

Thees all look good, but you may get into trouble if you trust a
PC with them!

If the language/PC uses floating point representation then it
will assign a fixed number of bits for the fractional part, and
this will be left aligned in all/most hardware. 

This fraction might be 52 bits long. Your example number has
about 11 bits of precision. The floating point representation
will then have ~40 bits appended which imply a precision
which does not exist. Your program may still know that only 11
bits are significant, but the representation implies that 52
bits are significant, and provides no indication otherwise. 

Good news!:  Unum is an alternate numeric representation that
does indicate the precision of a number [1].  It also resolves
other problems of current float representation.

Bad news?:In doing so unums becomes incompatible with current
hardware floating point engines. 

Jan Coombs
-- 
[1] slides:
http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf
RichReport 54 minute interview:
https://youtu.be/jN9L7TpMxeA

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

[issue27490] ARM cross-compile: pgen built without $(CFLAGS) as $(LIBRARY) dependency

[Thomas Perl]

Thomas Perl added the comment:

Also related: https://bugs.python.org/issue22359

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27131] Unit test random shuffle

[Jonathan Kross]

Jonathan Kross added the comment:

Just giving this one a bump to see if it can be applied soon.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26988] Add AutoNumberedEnum to stdlib

[John Hagen]

John Hagen added the comment:

>class BaseZeroEnum(Enum, start=0):
>   "initial integer is 0"
>   ...

I also think this looks better.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27490] ARM cross-compile: pgen built without $(CFLAGS) as $(LIBRARY) dependency

[Thomas Perl]

New submission from Thomas Perl:

Problem description: Trying to cross-compile $(LIBRARY) (libpython2.7.a for 
example) causes "pgen" to be built, even when it's not used in the 
cross-compilation case (only a file copy is done to generate $(GRAMMAR_H) and 
$(GRAMMAR_C)).


The current rule for $(PGEN) in Makefile.pre.in does not include $(CFLAGS):

https://hg.python.org/cpython/file/tip/Makefile.pre.in#l810

This causes problems when $(CFLAGS) changes the ARM float ABI, e.g.:

CFLAGS="-mfloat-abi=hard"

This causes the following issues at link time:

 1. The .o files that get linked into "pgen" are built with CFLAGS
(which is good, because some of them are used for libpython as well)
 2. When the "pgen" binary gets built, the $(CFLAGS) are not used
 3. Compiler fails to build "pgen" with different float ABI settings

=

[...]
arm-none-eabi-gcc -c -fno-strict-aliasing -march=armv6k -mtune=mpcore 
-mfloat-abi=hard -mtp=soft -fomit-frame-pointer -ffunction-sections -DARM11 
-D_3DS -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude 
-I./Include   -DPy_BUILD_CORE -o Parser/pgenmain.o Parser/pgenmain.c
arm-none-eabi-gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  
Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o 
Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o 
Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o 
Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o 
Parser/printgrammar.o Parser/pgenmain.o  -o Parser/pgen
/Users/thp/pkg/devkitPro/devkitARM/bin/../lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/bin/ld:
 error: Parser/acceler.o uses VFP register arguments, Parser/pgen does not
/Users/thp/pkg/devkitPro/devkitARM/bin/../lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/bin/ld:
 failed to merge target specific data of file Parser/acceler.o
[...]

=

Note that the error message is repeated for all .o files linked into pgen, I've 
only included one here for demonstration purposes. The following patch (against 
a Python 2.7.12 tarball, similar fix for Hg tip and Python 3) fixes the issue 
for me:

=
diff -u Python-2.7.12/Makefile.pre.in Python-2.7.12-fix/Makefile.pre.in
--- Python-2.7.12/Makefile.pre.in   2016-06-25 23:49:31.0 +0200
+++ Python-2.7.12-fix/Makefile.pre.in   2016-07-12 00:17:02.0 +0200
@@ -698,7 +698,7 @@
fi
 
 $(PGEN):   $(PGENOBJS)
-   $(CC) $(OPT) $(LDFLAGS) $(PGENOBJS) $(LIBS) -o $(PGEN)
+   $(CC) $(OPT) $(CFLAGS) $(LDFLAGS) $(PGENOBJS) $(LIBS) -o $(PGEN)
 
 Parser/grammar.o:  $(srcdir)/Parser/grammar.c \
$(srcdir)/Include/token.h \
=

Also note that the same $(CFLAGS) needs to be added to the rule for 
$(BUILDPYTHON) if one wants to build that as well, but in my case, I only did a 
"make libpython2.7.a", and that indirectly depends on pgen ($(LIBRARY) -> 
$(LIBRARY_OBJS) -> $(PYTHON_OBJS) -> Python/graminit.o -> $(GRAMMAR_C) -> 
$(GRAMMAR_H) -> $(PGEN), which results in that error message, so libpython2.7.a 
can't be built).

Another fix could be to make it so that $(GRAMMAR_H) does not depend on $(PGEN) 
if $(cross_compiling) is "yes" (if you read the rule contents for $(GRAMMAR_H), 
you'll find that indeed $(PGEN) isn't used at all if $(cross_compiling) is 
"yes". At least for GNU make, it might be possible to avoid building "pgen" in 
that case as follows and removing $(PGEN) from the default dependencies of 
$(GRAMMAR_H):

ifneq ($(cross_compiling),yes)
$(GRAMMAR_H): $(PGEN)
endif

If this is a more acceptable solution, one could probably rewrite the "test 
"$(cross_compiling" != "yes"; then..." part of the make rules from $(GRAMMAR_H) 
and $(GRAMMAR_C) with Make's ifeq, here's a patch for that instead (this also 
makes the dependencies more clear, since $(GRAMMAR_H) does not depend on 
$(GRAMMAR_INPUT) for the cross-input case, as it is not used):

=
diff -u Python-2.7.12/Makefile.pre.in Python-2.7.12-fix/Makefile.pre.in
--- Python-2.7.12/Makefile.pre.in   2016-06-25 23:49:31.0 +0200
+++ Python-2.7.12-fix/Makefile.pre.in   2016-07-12 00:37:43.0 +0200
@@ -680,22 +680,21 @@
 
 Modules/pwdmodule.o: $(srcdir)/Modules/pwdmodule.c 
$(srcdir)/Modules/posixmodule.h
 
+ifeq ($(cross_compiling),yes)
+$(GRAMMAR_H): $(srcdir)/Include/graminit.h
+   @$(MKDIR_P) Include
+   cp $(srcdir)/Include/graminit.h $(GRAMMAR_H).tmp
+   mv $(GRAMMAR_H).tmp $(GRAMMAR_H)
+$(GRAMMAR_C): $(srcdir)/Python/graminit.c
+   cp $(srcdir)/Python/graminit.c $(GRAMMAR_C).tmp
+   mv $(GRAMMAR_C).tmp $(GRAMMAR_C)
+else
 $(GRAMMAR_H): $(GRAMMAR_INPUT) $(PGEN)
@$(MKDIR_P) Include
-   # Avoid copying the file onto itself for an in-tree build
-   if test "$(cross_compiling)" != "yes"; then \
-   $(PGEN) $(GRAMMAR_INPUT) $(GRAMMAR_H) $(GRAMMAR_C); \
-   else \
-   cp $(srcdir)/Include/graminit.h $(GRAMMAR_H).tmp; \
-   

Re: What is precision of a number representation?

[Ben Bacarisse]

Ben Finney  writes:

> Ethan Furman  writes:
>
>> I will readily admit to not having a maths degree, and so of course to
>> me saying the integer 123 has a precision of 5, 10, or 99 digits seems
>> like hogwash to me.
>
> Precision is not a property of the number. It is a property of the
> *representation* of that number.
>
> The representation “1×10²” has a precision of one digit.
> The representation “100” has a precision of three digits.
> The representation “00100” has a precision of five digits.
> The representation “100.00” also has a precision of five digits.

What is your source for the third one?  I've never seen the term used
in this way so I'm curious about how widely it's used.  (I disagree with
the second one, too, but that's an old argument that does not need
resurrecting.)

> Those can all represent the same number; or maybe some of them represent
> “one hundred” and others represent “one hundred and a millionth”.

So 00100 represents the range [99.995, 100.005] just like 100.00?
That's new to me.  It is more than a Python thing?


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

Re: What is precision of a number representation?

[Ethan Furman]

On 07/11/2016 03:17 PM, Ethan Furman wrote:


So, so far there is no explanation of why leading zeroes make a number
more precise.


An example of what I mean:

174 with a precision of 3 tells us that the tenths place could be any of 
0-9, or, put another way, the actual number could be anywhere between 
174.0 to 174.9 (or maybe 173.5 to 174.5).  If we have 174 with four 
digits of precision, then the representation should be 174.0 and it's 
the hundreths we are unsure of.


So my question is: if we write 174 when could the thousands /ever/ be 
anything besides 0?


--
~Ethan~

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

Re: What is precision of a number representation?

[Ethan Furman]

On 07/11/2016 02:51 PM, Chris Angelico wrote:

On Tue, Jul 12, 2016 at 6:56 AM, Ben Finney wrote:



Precision is not a property of the number. It is a property of the
*representation* of that number.

The representation “1×10²” has a precision of one digit.
The representation “100” has a precision of three digits.
The representation “00100” has a precision of five digits.
The representation “100.00” also has a precision of five digits.

Those can all represent the same number; or maybe some of them represent
“one hundred” and others represent “one hundred and a millionth”.



Yep. Precision is also a property of a measurement, the same way that
a unit is. If I pace out the length of the main corridor in my house,
I might come up with a result of thirty meters. The number is "30";
the unit is "meters", the precision is two significant digits, and the
accuracy depends on how good I am at pacing distance.

This is why it's important to be able to record precisions of
arbitrary numbers. If I then measure the width of this corridor with a
laser, I could get an extremely precise answer - say, 2,147
millimeters, with a precision of four significant digits, and
excellent accuracy. But if I multiply those numbers together to
establish the floor area of the corridor, the result does NOT have
four significant figures. It would be 64 square meters (not 64.41),
and the accuracy would be pretty low (effectively, the *in*accuracies
of both measurements get combined). But on the other hand, if you want
to know whether your new fridge will fit, you could measure it with
the same laser and come up with a figure of 1,973 mm (four sig fig),
which would mean your clearance is 174mm (four sig fig). How do you
record this? Is it 174.0? 0174? "174 with four significant figures"?


174.0, because those last tenths of a millimeter could be very 
important, while knowledge that there are no thousands of millimeters is 
already present.


So, so far there is no explanation of why leading zeroes make a number 
more precise.


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

[issue13402] Document absoluteness of sys.executable

[Brad Larsen]

Brad Larsen added the comment:

It looks like sys.executable is *not* always an absolute path.  In Python 2.7:

$ which python2.7
/opt/local/bin/python2.7
$ cd /opt/local/bin
$ ../bin/python2.7 -m 'import sys; print(sys.executable)'
/opt/local/bin/../bin/python2.7

Also in Python 3.5:

$ which python3.5
/opt/local/bin/python3.5
$ cd /opt/local/bin
$ ../bin/python3.5 -m 'import sys; print(sys.executable)'
/opt/local/bin/../bin/python3.5

--
nosy: +blarsen

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27489] Win 10, choco install python gets message: Access to the path 'C:\WINDOWS\system32\**\**.exe.ignore' is denied.

[Eryk Sun]

Changes by Eryk Sun :


--
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats)

[Chris Angelico]

On Tue, Jul 12, 2016 at 6:56 AM, Ben Finney  wrote:
> Precision is not a property of the number. It is a property of the
> *representation* of that number.
>
> The representation “1×10²” has a precision of one digit.
> The representation “100” has a precision of three digits.
> The representation “00100” has a precision of five digits.
> The representation “100.00” also has a precision of five digits.
>
> Those can all represent the same number; or maybe some of them represent
> “one hundred” and others represent “one hundred and a millionth”.
>

Yep. Precision is also a property of a measurement, the same way that
a unit is. If I pace out the length of the main corridor in my house,
I might come up with a result of thirty meters. The number is "30";
the unit is "meters", the precision is two significant digits, and the
accuracy depends on how good I am at pacing distance.

This is why it's important to be able to record precisions of
arbitrary numbers. If I then measure the width of this corridor with a
laser, I could get an extremely precise answer - say, 2,147
millimeters, with a precision of four significant digits, and
excellent accuracy. But if I multiply those numbers together to
establish the floor area of the corridor, the result does NOT have
four significant figures. It would be 64 square meters (not 64.41),
and the accuracy would be pretty low (effectively, the *in*accuracies
of both measurements get combined). But on the other hand, if you want
to know whether your new fridge will fit, you could measure it with
the same laser and come up with a figure of 1,973 mm (four sig fig),
which would mean your clearance is 174mm (four sig fig). How do you
record this? Is it 174.0? 0174? "174 with four significant figures"?

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

[issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache

[Mihai Capotă]

Changes by Mihai Capotă :


--
nosy: +mihaic

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Touch screen development in Python

[Laurent Pointal]

Jahn wrote:

> Hi ,
> Does anyone use Python for  developping  applications that  work with a
> touch screen?

You should take a look at Kivy: https://kivy.org/

A+
L.Pointal.

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

Re: What is precision of a number representation?

[Ethan Furman]

On 07/11/2016 01:56 PM, Ben Finney wrote:


Precision is not a property of the number. It is a property of the
*representation* of that number.

The representation “1×10²” has a precision of one digit.
The representation “100” has a precision of three digits.
The representation “00100” has a precision of five digits.
The representation “100.00” also has a precision of five digits.


Your first, second, and fourth example have zeroes to the right, and I 
understand them just fine.


Your third example has zeroes to the left, and you haven't explained how 
00100 is more precise than 100.  I mean, if somebody told me that one 
hundred was closer to one hundred than it was to ten thousand I would 
have to say "D'oh!"



We gain clarity of speech: we distinguish the different aspects (how
many digits of this representation are actually claimed to represent the
number?) communicated by a representation.


Nope, still not clear to me.  :(

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

[issue27489] Win 10, choco install python gets message: Access to the path 'C:\WINDOWS\system32\**\**.exe.ignore' is denied.

[Joel Handwell]

Changes by Joel Handwell :


--
resolution:  -> third party

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

What is precision of a number representation? (was: Curious Omission In New-Style Formats)

[Ben Finney]

Ethan Furman  writes:

> I will readily admit to not having a maths degree, and so of course to
> me saying the integer 123 has a precision of 5, 10, or 99 digits seems
> like hogwash to me.

Precision is not a property of the number. It is a property of the
*representation* of that number.

The representation “1×10²” has a precision of one digit.
The representation “100” has a precision of three digits.
The representation “00100” has a precision of five digits.
The representation “100.00” also has a precision of five digits.

Those can all represent the same number; or maybe some of them represent
“one hundred” and others represent “one hundred and a millionth”.

The representation is only an approximation of the actual number, and
the precision tells us how fuzzy the approximation is.

None of these say how *accurate* the representation is; if those are
representations of the number “seven thousand” they are not very
accurate, while they might be passably accurate for the number “one
hundred and seventy”.

> But I'm always willing to learn.  So please explain what 123 with a
> precision of five integer digits means, and what to do we gain by
> saying such a thing?

We gain clarity of speech: we distinguish the different aspects (how
many digits of this representation are actually claimed to represent the
number?) communicated by a representation.

-- 
 \“… no testimony can be admitted which is contrary to reason; |
  `\   reason is founded on the evidence of our senses.” —Percy Bysshe |
_o__)Shelley, _The Necessity of Atheism_, 1811 |
Ben Finney

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

[issue27489] Win 10, choco install python gets message: Access to the path 'C:\WINDOWS\system32\**\**.exe.ignore' is denied.

[Joel Handwell]

New submission from Joel Handwell:

While installing python 3.5.1 using chocolatey package manager on Windows 10, I 
got following message:

python3 v3.5.1
WARNING: The names of some imported commands from the module 
'chocolateyInstaller' include unapproved verbs that might make them less 
discoverable. To find the commands with unapproved verbs, run the Import-Module 
command again with the Verbose parameter. For a list of approved verbs, type 
Get-Verb.
Downloading python3 64 bit
  from 'https://www.python.org/ftp/python/3.5.1/python-3.5.1-amd64.exe'
Progress: 100% - Saving 28.25 MB of 28.25 MB (29627072/29627072)
Download of python3Install.exe (28.25 MB) completed.
Installing python3...
python3 has been installed.
Access to the path 'C:\WINDOWS\system32\Boot\winload.exe.ignore' is denied.
Access to the path 'C:\WINDOWS\system32\Boot\winresume.exe.ignore' is denied.
Access to the path 
'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\difx64.exe.ignore'
 is denied.
Access to the path 
'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\DPTopologyApp.exe.ignore'
 is denied.
Access to the path 
'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\DPTopologyAppv2_0.exe.ignore'
 is denied.
Access to the path 
'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\GfxUIEx.exe.ignore'
 is denied.
Access to the path 
'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\Gfxv2_0.exe.ignore'
 is denied.
Access to the path 
'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\Gfxv4_0.exe.ignore'
 is denied.
Access to the path 
'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\igfxCUIService.exe.ignore'
 is denied.
Access to the path 
'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\igfxEM.exe.ignore'
 is denied.
Access to the path 
'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\igfxext.exe.ignore'
 is denied.
Access to the path 
'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\igfxHK.exe.ignore'
 is denied.

--
components: Installation
messages: 270209
nosy: joelhandwell
priority: normal
severity: normal
status: open
title: Win 10, choco install python gets message: Access to the path 
'C:\WINDOWS\system32\**\**.exe.ignore' is denied.
type: behavior
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Curious Omission In New-Style Formats

[Terry Reedy]

On 7/11/2016 3:27 PM, Ian Kelly wrote:

On Mon, Jul 11, 2016 at 12:54 PM, Terry Reedy  wrote:

In any case, I think it an improvement to say that '0x00123' has a field
width of 7 rather than a 'precision' of 5.


'{:#07x}'.format(0x123)  # specifiy field width

'0x00123'

"%#0.5x" % 0x123  # specify int precision

'0x00123'


It occurs to me now that this does create a challenge if the format is
meant to support negative numbers as well:


'%#0.5x' % -0x123

'-0x00123'


This expands the field from 7 to 8 chars.  In running text, this is 
alright.  In formatted table columns, it is not.



'{:#07x}'.format(-0x123)

'-0x0123'


Multiple alternatives

>>> '{: #08x} {: #08x}'.format(0x123, -0x123)
' 0x00123 -0x00123'
>>> '{:+#08x} {:+#08x}'.format(0x123, -0x123)
'+0x00123 -0x00123'
>>> '{0:#0{1}x} {2:+#0{3}x}'.format(0x123, 7, -0x123, 8)
'0x00123 -0x00123'
>>> n1, n2, w = 0x123, -0x123, 7
>>> '{0:#0{1}x} {2:+#0{3}x}'.format(n1, w+(n1<0), n2, w+(n2<0))
'0x00123 -0x00123'

In running text, I ight go with '+','-' prefix.

--
Terry Jan Reedy

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

[issue27488] Underscore not showing Mac El Capitan

[Zachary Ware]

Zachary Ware added the comment:

This is due to changes in the default font settings for IDLE.  You can boost 
your font size and/or pick a different font, and your underscores will appear.

3.4 is no longer receiving bug fixes (or binary installers), so there's nothing 
we can do here.

--
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: EuroPython 2016: Last day to get tickets at regular rate

[Moritz Neeb]

Actually this was not your last chance! I am offering one spare regular
rate student ticket (120,-). Please contact me if interested.

Cheers,
Moritz

On 07/07/2016 09:35 AM, M.-A. Lemburg wrote:
> We will be switching to the on-desk rates for tickets tomorrow, so
> today is your last chance to get tickets at the regular rate, which is
> about 30% less than the on-desk rate:
> 
> 
>EuroPython 2016 Registration
> 
> *** https://ep2016.europython.eu/registration/ ***
> 
> 
> 
> Day Passes
> --
> 
> As in the past, we will also sell day passes at the conference venue.
> 
> To make things more affordable especially for students and other
> people who want to attend the Beginners’ Day or the sprints, we have
> split the day pass prices into ones valid from Monday-Friday for the
> main conference days and ones for the weekend days.
> 
> Day passes for the first Sunday (Beginners’ Day) and the sprints
> weekend (valid for the day when they are purchased):
> 
>  * Student weekend day pass: EUR 25.00
>  * Personal weekend day pass: EUR 70.00
>  * Business weekend day pass: EUR 110.00
> 
> Day passes for the main conference (valid for the day when they are
> purchased):
> 
>  * Student conference day pass: EUR 50.00
>  * Personal conference day pass: EUR 140.00
>  * Business conference day pass: EUR 225.00
> 
> All prices include 10% Spanish VAT. Please see the registration page
> for full details of what is included in the ticket price.
> 
> 
> 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/750955219975016448
> Thanks.
> 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Random832]

On Mon, Jul 11, 2016, at 16:06, Michael Torrie wrote:
> I'm not sure I've ever seen a negative hex number in the wild. Usually
> when I view a number in hex I am wanting the raw representation.  -0x123
> with a width of 7 would be 0xFFEDD

There's nothing "raw" about python int objects. To get what you want,
you need to do x & 0xf

If you have "5" as a parameter, you can get the desired constant as (1
<< x*4) - 1.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26877] tarfile use wrong code when read from fileobj

[Марк Коренберг]

Марк Коренберг added the comment:

http://stackoverflow.com/questions/1964806/short-read-from-filesystem-when-can-it-happen

Disk-based filesystems generally use uninterruptible reads, which means that 
the read operation generally cannot be interrupted by a signal. Network-based 
filesystems sometimes use interruptible reads, which can return partial data or 
no data. (In the case of NFS this is configurable using the intr mount option.) 
They sometimes also implement timeouts.

> can return partial data

Seems reading tar-file from NFS-filesystem may trigger that bug.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16858] tarfile silently hides errors

[Марк Коренберг]

Марк Коренберг added the comment:

What the hell! sorry again :(

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27488] Underscore not showing Mac El Capitan

[Monti Carlo]

New submission from Monti Carlo:

Trying to type in underscore and it just made a space... Downloaded 3.5.2 and 
it works fine.

--
components: IDLE
messages: 270205
nosy: Monti Carlo
priority: normal
severity: normal
status: open
title: Underscore not showing Mac El Capitan
versions: Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16858] tarfile silently hides errors

[Марк Коренберг]

Марк Коренберг added the comment:

http://stackoverflow.com/questions/1964806/short-read-from-filesystem-when-can-it-happen

Disk-based filesystems generally use uninterruptible reads, which means that 
the read operation generally cannot be interrupted by a signal. Network-based 
filesystems sometimes use interruptible reads, which can return partial data or 
no data. (In the case of NFS this is configurable using the intr mount option.) 
They sometimes also implement timeouts.

> can return partial data

Seems reading tar-file from NFS-filesystem may trigger that bug.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27484] Some Examples in Format String Syntax are incorrect or poorly worded

[R. David Murray]

R. David Murray added the comment:

Agree with Zach.  The example comments are correct as written, especially when 
considered in the context of the preceding example.

--
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

[Wolfgang Maier]

New submission from Wolfgang Maier:

As a result of Issue14285 Python 3.5.2 now imports packages in runpy. 
_get_module_details before calling importlib.util.find_spec.

Although I'm not sure how important this is, I wanted to report that this new 
behaviour can have a side-effect under pretty exotic circumstances. When 
__init__.py imports the same module that is supposed to be invoked via the -m 
switch and that module replaces its own entry in sys.modules with another 
object, this causes importlib.util.find_spec to fail with a *very* cryptic:

Error while finding spec for 'package.module' (ValueError: 
package.module.__spec__ is not set)

without an exception traceback.

I have no idea whether any other package would be affected by this, but it took 
me quite some time today to trace the cause of this and it is not what you'd 
expect from a maintenance release. I think the changed behaviour in runpy 
should at least be documented (beyond just mentioning the issue in the 
changelog).

--
components: Library (Lib)
messages: 270202
nosy: martin.panter, ncoghlan, wolma
priority: normal
severity: normal
status: open
title: -m switch regression in Python 3.5.2 (under rare circumstances)
type: behavior
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Curious Omission In New-Style Formats

[Michael Torrie]

On 07/11/2016 01:27 PM, Ian Kelly wrote:
> On Mon, Jul 11, 2016 at 12:54 PM, Terry Reedy  wrote:
>> In any case, I think it an improvement to say that '0x00123' has a field
>> width of 7 rather than a 'precision' of 5.
>>
> '{:#07x}'.format(0x123)  # specifiy field width
>> '0x00123'
> "%#0.5x" % 0x123  # specify int precision
>> '0x00123'
> 
> It occurs to me now that this does create a challenge if the format is
> meant to support negative numbers as well:
> 
 '%#0.5x' % -0x123
> '-0x00123'
 '{:#07x}'.format(-0x123)
> '-0x0123'

I'm not sure I've ever seen a negative hex number in the wild. Usually
when I view a number in hex I am wanting the raw representation.  -0x123
with a width of 7 would be 0xFFEDD



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

Re: Touch screen development in Python

[Dietmar Schwertberger]

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

Re: Compression of random binary data

[Terry Reedy]

On 7/11/2016 2:09 PM, Joonas Liik wrote:

On 11 July 2016 at 20:52,   wrote:

What kind of statistic law or mathematical conjecture  or is it
even a physical law is violated by compression of random binary
data?


Off-topic, but...  It is unclear whether you mean 'random' in the 
technical sense of 'unpredictable' or the common sense that adds 'of 
equal probability'.


Bell engineers discovered that physical communication channels have a 
finite information transmission capacity that could be formalized as 
bits per second.  You should be able to find good articles on the web, 
and I suggest you read some.


If every message could be compressed, than every message could be 
compressed to 0 or 1, which is absurd.



I only know that Shanon [Shannon] theorised it could not be done, but were
there any proof?


Shannon meant random in the technical sense and explicitly considered 
unequal probabilities.  Random bit streams with unequal probabilities 
*can* be compressed by recoding.



Compression relies on some items in the dataset being more frequent
than others,


Perhaps better to say that compression relies on removing redundancy, 
*if there is any*.  The two ideas are related.



if you have some dataset that is completely random it
would be hard to compress as most items have very similar number of
occurrances.


Assuming equal bit probabilities.  Uncorrelated bits of unequal 
probability results in blocks of whatever size having unequal 
probabilites and redundancy that can be removed by replacing blocks with 
coded blocks.  Huffman encoding does this by replacing blocks of equal 
size with code blocks of unequal size, with the size related to the 
probability of the block replaced.


--
Terry Jan Reedy

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

Re: Curious Omission In New-Style Formats

[Ian Kelly]

On Mon, Jul 11, 2016 at 12:54 PM, Terry Reedy  wrote:
> In any case, I think it an improvement to say that '0x00123' has a field
> width of 7 rather than a 'precision' of 5.
>
 '{:#07x}'.format(0x123)  # specifiy field width
> '0x00123'
 "%#0.5x" % 0x123  # specify int precision
> '0x00123'

It occurs to me now that this does create a challenge if the format is
meant to support negative numbers as well:

>>> '%#0.5x' % -0x123
'-0x00123'
>>> '{:#07x}'.format(-0x123)
'-0x0123'
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26988] Add AutoNumberedEnum to stdlib

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On Jul 11, 2016, at 07:05 PM, Ethan Furman wrote:

>class BaseZeroEnum(Enum, start=0):
>   "initial integer is 0"
>   ...
>
>?  Oh, and yes if you specify a starting number you also activate the
>AutoNumber feature.

I like the way this one looks.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27485] urllib.splitport -- is it official or not?

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

splitport() doesn't work with IPv6 ("[::1]", see issue18191), nor with 
authority ("user:passw...@example.com"). Note that there is a almost duplicate 
function splitnport(). The existence of two similar functions that behave 
differently in corner cases looks confusing. And seems splitport() and 
splitnport() not always used correctly internally (see issue20271).

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26988] Add AutoNumberedEnum to stdlib

[Ethan Furman]

Ethan Furman added the comment:

If you are constructing your own base Enum type, which would you rather do?

class BaseZeroEnum(Enum):
   "initial integer is 0"
   _start_ = 0
   ...

or

class BaseZeroEnum(Enum, start=0):
   "initial integer is 0"
   ...

?  Oh, and yes if you specify a starting number you also activate the 
AutoNumber feature.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Compression of random binary data

[Nobody]

On Mon, 11 Jul 2016 10:52:08 -0700, jonas.thornvall wrote:

> What kind of statistic law or mathematical conjecture  or is it even a
> physical law is violated by compression of random binary data?

You can't create an invertable mapping between a set with 2^N elements
(e.g. the set of all N-bit binary sequences) and any set with fewer than
2^N elements (e.g. the set of all M-bit binary sequences for M

Re: Compression of random binary data

[MRAB]

On 2016-07-11 19:30, MRAB wrote:

On 2016-07-11 18:52, jonas.thornv...@gmail.com wrote:

What kind of statistic law or mathematical conjecture  or is it even a physical 
law is violated by compression of random binary data?

I only know that Shanon theorised it could not be done, but were there any 
proof?

What is to say that you can not do it if the symbolic representation is richer 
than the symbolic represenatation of the dataset.

Isn't it a fact that the set of squareroots actually depict numbers in a 
shorter way than their actual representation.

Now the inpretator or program must know the rules. And i have very good rules 
to make it happen.


If you want a challenge:

The Enduring Challenge of Compressing Random Data
http://www.drdobbs.com/architecture-and-design/the-enduring-challenge-of-compressing-ra/240049914

It turns out there's a newsgroup for compression, and they're used to 
getting claims about compressing random data. In fact, so much so that 
it's in their FAQ:


comp.compression Frequently Asked Questions (part 1/3)
Section - [9] Compression of random data (WEB, Gilbert and others)
http://www.faqs.org/faqs/compression-faq/part1/section-8.html

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

Re: Curious Omission In New-Style Formats

[Terry Reedy]

On 7/11/2016 1:24 PM, Ethan Furman wrote:

On 07/11/2016 09:28 AM, Steven D'Aprano wrote:

On Tue, 12 Jul 2016 01:04 am, Ian Kelly wrote:



Er, what? I count *five* digits in "00123", not three.

You seem to be assuming that "precision" can only refer to digits
after the
decimal place, but that's a dubious proposition.


I will readily admit to not having a maths degree, and so of course to
me saying the integer 123 has a precision of 5, 10, or 99 digits seems
like hogwash to me.


I do have an undergraduate degree in math and a career in statistics, 
and I cannot remember seen 'precision' used in relation to integers.  So 
I would call it a 'non-standard extension' of the notion.



But I'm always willing to learn.  So please explain what 123 with a
precision of five integer digits means,


What it could mean is that we have an count selected from the range 
0 to 9 inclusive.  But what I just said is the usual way of 
saying that, as it does not limit the lower and upper limits to 0s and 9s.



and what to do we gain by saying such a thing?


Confusion.

Precision is usually used in reference to measurement, and while 
measurement is based on counting, it is not the same thing.  If 123 is a 
count, then its precision is 1 count, not k digits.  Or one could say 
that all digits are precise. What is ambiguous without context is 
whether counts with trailing 0s, like 120 or 100 are exact or rounded. 
100, as a cound, could have a precision of 1, 2, or 3 (significant) 
digits.  Context sometimes says things like 'to the nearest hundred 
thousand'.


In any case, I think it an improvement to say that '0x00123' has a field 
width of 7 rather than a 'precision' of 5.


>>> '{:#07x}'.format(0x123)  # specifiy field width
'0x00123'
>>> "%#0.5x" % 0x123  # specify int precision
'0x00123'

Thus, my title for a post noting the same change might be "Upgrade in 
new-style formats".

(format and If one want leading 0s,

--
Terry Jan Reedy

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

[issue27486] FTPlib hangs on some pasv responses

[SilentGhost]

Changes by SilentGhost :


--
nosy: +giampaolo.rodola
stage:  -> test needed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27486] FTPlib hangs on some pasv responses

[송병우]

New submission from 송병우:

FTPlib hangs on PASV responses when the connected server is within its local 
network.
Here's my fix that checks the target address with ipaddress lib:
https://github.com/python/cpython/pull/28/files

--
components: Library (Lib)
messages: 270198
nosy: 송병우
priority: normal
severity: normal
status: open
title: FTPlib hangs on some pasv responses
type: enhancement
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Compression of random binary data

[Steven D'Aprano]

On Tue, 12 Jul 2016 03:52 am, jonas.thornv...@gmail.com wrote:

> What kind of statistic law or mathematical conjecture  or is it even a
> physical law is violated by compression of random binary data?

The pigeon hole principle. If you have 100 pigeon holes, and 101 pigeons,
then clearly at least one pigeon hole must have two pigeons in it.

To keep the numbers small and manageable, let's say we are going to compress
one byte at a time. Now a byte has eight bits, so there are exactly 256
possible bytes:

 
 0001
 0010
...
 1110
 

Now, suppose I claim that I can LOSSLESSLY (that is, reversibly) compress
any random byte to just two bits. The lossless part is important: its not
hard to compress random data by irreversibly throwing some of it away, and
there's no violation there.

So I claim that you can give me any random byte, I will compress it to just
two bits:

00
01
10
11

and then be able to decompress it back again to give you the original byte
once more.

Obviously I'm trying to pull a fast one! There's no way I can do this. I can
squeeze 256 pigeons into just four pigeon holes, but only by doubling them
up. Suppose I compress these three bytes to 00:

 
0110 1001
1100 0110

Now when I go to uncompress 00, what should I return? There is no way for me
to know which of the three was the original value.

(If I'm cunning, I'll have sneakily stored some data *elsewhere*, say, in
the file name, or in a database, so that you need this extra hidden data to
uncompress the 00 back to a full byte. But then I'm not compressing eight
bits down to two. I'm compressing eight bits down to two bits plus
who-knows-how-many-bits of hidden data.)

So the pigeon hole principle tells us one of two things:

(1) If you compress random data, then it must be lossy; I can compress eight
bits to two, but then I can't uncompress it back again, at least not
without throwing away some data.

(2) Or, if the compression is lossless, then some data must be expanded
rather than compressed. If you pick data at random, some of it will be
expanded.

Suppose I have a compression algorithm that infallibly and reversibly
compresses as follows:

  <--> 00
 0001 <--> 01
 0010 <--> 10
 0011 <--> 11

That part is fine. But what will my algorithm do with the other 252 bytes?
At *best* it will leave them untouched:

 0100 <-->  0100
...
  <-->  

which is no compression at all, but at worst it will actually expand them
and make them bigger. (After all, it's likely that my compression format
has at least a bit of overhead.)

In practice, compression algorithms are designed to look for particular
kinds of order or structure in the data, and compress that. That's fine for
the sorts of non-random data we care about: pictures are rarely pictures of
static, text files are rarely random collections of bits. But if you do
throw a random set of bits at a lossless compression algorithm, it will at
best not compress it at all, and at worst actually make the file bigger.


> What is to say that you can not do it if the symbolic representation is
> richer than the symbolic represenatation of the dataset.
> 
> Isn't it a fact that the set of squareroots actually depict numbers in a
> shorter way than their actual representation.

Sure. But you need to know what √2 means. It *represents* the number
1.41421356237... but doesn't compress it. There's nothing you can do to the
symbol √2 that will uncompress back to the infinite series of digits. All
you can do is look it up somewhere to see what the digits are.

> Now the inpretator or program must know the rules. And i have very good
> rules to make it happen.

Right. How much information is in the rules? More than you save with
the "compression". Consider:

1.41421356237 compressed down to √2, that's 13 characters down to 2. Great!
But to *uncompress*, you need to store a rule:

√2=1.41421356237 

and that's *sixteen* characters. So your "compression" is:

original: 13
compressed to: 2
plus rule: 16

means you have "compressed" 13 characters to 18.

Now, this is still worth doing if you need to repeat the √2 many times, so
long as you don't have to repeat the rule. That's useful. But it's not
compression. It's more like keeping an index to a database, or a scrap of
paper with the title of a book written on it:

"See Lord Of The Rings, by J.R.R. Tolkien"

That's a lot smaller than the actual book: eight words, instead of who knows
how many tens of thousands. But you can't call it compression: you can't
sit down with the scrap of paper *and nothing else* and uncompress it back
to the entire LOTR trilogy.




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

[Ian Kelly]

On Mon, Jul 11, 2016 at 10:28 AM, Steven D'Aprano  wrote:
> On Tue, 12 Jul 2016 01:04 am, Ian Kelly wrote:
>> Your example showed a 3-digit number being formatted with a requested
>> precision of 5 digits. The way this was done was by left-padding the
>> number with 0s until there were 5 digits,
>
> Right.
>
>> but still only 3 digits of precision.
>
> Er, what? I count *five* digits in "00123", not three.
>
> You seem to be assuming that "precision" can only refer to digits after the
> decimal place, but that's a dubious proposition. That might be the way
> printf interprets the precision for *floats*, but its not the way it
> interprets the precision for *ints*, and who is to say that one way is
> right and the other is wrong?

In what way do the leading zeroes in "00123" add to the precision of
the number? 00123 is the same quantity as 123 and represents no more
precise a measurement. Neither does 000123 for "ten" digits of
precision. We could just keep adding zeroes ad nauseam and then claim
that 123 has infinite precision.

Clearly, that's wrong.

>> If you truly wanted to format the number with a precision
>> of 5 digits, it would look like this:
>>
>> 0x123.00
>
> Er, no, because its an integer.

Which is why if you actually want to do this, you should convert it to
a decimal or a float first (of course, those don't support hexadecimal
output, so if you actually want hexadecimal output *and* digits after
the (hexa)decimal point, then I think you would just have to roll your
own formatting at that point).

>> It may happen to do what you want in the printf-style format, but
>> calling the field "precision" is at best misleading, and there are
>> other ways to accomplish the same result.
>
> Naturally. So why bother to have .format() or % in the first place? There's
> always other ways to accomplish the same result.

I think it's just a case of purity winning out over practicality. As I
said before, I don't really know why the decision was made to not
support or allow it. What I've written above was my best guess.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[jonas . thornvall]

Den måndag 11 juli 2016 kl. 20:24:37 UTC+2 skrev jonas.t...@gmail.com:
> Den måndag 11 juli 2016 kl. 20:09:39 UTC+2 skrev Waffle:
> > On 11 July 2016 at 20:52,   wrote:
> > > What kind of statistic law or mathematical conjecture  or is it even a 
> > > physical law is violated by compression of random binary data?
> > >
> > > I only know that Shanon theorised it could not be done, but were there 
> > > any proof?
> > 
> > Compression relies on some items in the dataset being more frequent
> > than others, if you have some dataset that is completely random it
> > would be hard to compress as most items have very similar number of
> > occurrances.
> > 
> > > What is to say that you can not do it if the symbolic representation is 
> > > richer than the symbolic represenatation of the dataset.
> > >
> > > Isn't it a fact that the set of squareroots actually depict numbers in a 
> > > shorter way than their actual representation.
> > 
> > A square root may be smaller numerically than a number but it
> > definitely is not smaller in terms of entropy.
> > 
> > lets try to compress the number 2 for instance using square roots.
> > sqrt(2) = 1.4142
> > the square root actually takes more space in this case even tho it is
> > a smaller number. so having the square root would have negative
> > compression in this case.
> > with some rounding back and forth we can probably get around the fact
> > that sqrt(2) would take an infinite amout of memory to accurately
> > represent but that neccesarily means restricting the values we are
> > possible of encoding.
> > 
> > for sqrt(2) to not have worse space consumprion than the number 2
> > itself we basically have to trow away precision so sqrt(2) ~= 1
> > now i challenge you to get that 2 back out of that 1..
> 
> Well who it to say different kind of numbers isn't treated differently, i 
> mean all numbers isn't squares. All numbers isn't naturals.

But it could be all numbers are foldable. Both the integer parts and the real 
parts.And be expressed by the folding differences.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Compression of random binary data

[MRAB]

On 2016-07-11 18:52, jonas.thornv...@gmail.com wrote:

What kind of statistic law or mathematical conjecture  or is it even a physical 
law is violated by compression of random binary data?

I only know that Shanon theorised it could not be done, but were there any 
proof?

What is to say that you can not do it if the symbolic representation is richer 
than the symbolic represenatation of the dataset.

Isn't it a fact that the set of squareroots actually depict numbers in a 
shorter way than their actual representation.

Now the inpretator or program must know the rules. And i have very good rules 
to make it happen.


If you want a challenge:

The Enduring Challenge of Compressing Random Data
http://www.drdobbs.com/architecture-and-design/the-enduring-challenge-of-compressing-ra/240049914

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

[issue27484] Some Examples in Format String Syntax are incorrect or poorly worded

[Zachary Ware]

Zachary Ware added the comment:

I don't think "argument first" should be changed to "first argument": the point 
is that the converter is called on the argument before it's formatted into the 
string, the call is done "first".

--
nosy: +zach.ware

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27285] Document the deprecation of pyvenv in favor of `python3 -m venv`

[Ned Deily]

Ned Deily added the comment:

Thanks for the fix up, Steve.  For 3.6.0a3, I chose to just change the 3.3 and 
3.4 whatsnew references to just in-line code without any links.  If anyone 
wants something fancier, please feel free to expand on it (after the release).

(BTW, Steve, when you submit an updated patch, please do so against the current 
tip of the branch; most of your update patch had already been committed by 
Brett.)

--
nosy: +ned.deily
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Compression of random binary data

[jonas . thornvall]

Den måndag 11 juli 2016 kl. 20:09:39 UTC+2 skrev Waffle:
> On 11 July 2016 at 20:52,   wrote:
> > What kind of statistic law or mathematical conjecture  or is it even a 
> > physical law is violated by compression of random binary data?
> >
> > I only know that Shanon theorised it could not be done, but were there any 
> > proof?
> 
> Compression relies on some items in the dataset being more frequent
> than others, if you have some dataset that is completely random it
> would be hard to compress as most items have very similar number of
> occurrances.
> 
> > What is to say that you can not do it if the symbolic representation is 
> > richer than the symbolic represenatation of the dataset.
> >
> > Isn't it a fact that the set of squareroots actually depict numbers in a 
> > shorter way than their actual representation.
> 
> A square root may be smaller numerically than a number but it
> definitely is not smaller in terms of entropy.
> 
> lets try to compress the number 2 for instance using square roots.
> sqrt(2) = 1.4142
> the square root actually takes more space in this case even tho it is
> a smaller number. so having the square root would have negative
> compression in this case.
> with some rounding back and forth we can probably get around the fact
> that sqrt(2) would take an infinite amout of memory to accurately
> represent but that neccesarily means restricting the values we are
> possible of encoding.
> 
> for sqrt(2) to not have worse space consumprion than the number 2
> itself we basically have to trow away precision so sqrt(2) ~= 1
> now i challenge you to get that 2 back out of that 1..

Well who it to say different kind of numbers isn't treated differently, i mean 
all numbers isn't squares. All numbers isn't naturals.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27235] Heap overflow occurred due to the int overflow (Python-2.7.11/Modules/posixmodule.c)

[Brian Martin]

Changes by Brian Martin :


--
nosy: +osvdb
status: pending -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27285] Document the deprecation of pyvenv in favor of `python3 -m venv`

[Roundup Robot]

Roundup Robot added the comment:

New changeset 2a34cef7681b by Ned Deily in branch 'default':
Issue #27285: Cleanup "suspicious" warnings.
https://hg.python.org/cpython/rev/2a34cef7681b

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Touch screen development in Python

[Wildman via Python-list]

On Mon, 11 Jul 2016 19:21:56 +0200, Jahn wrote:

> Hi ,
> Does anyone use Python for  developping  applications that  work with a touch 
> screen?
> 

http://www.technolabsz.com/2011/08/how-to-make-touch-screen-user-interface.html

-- 
 GNU/Linux user #557453
The cow died so I don't need your bull!
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27484] Some Examples in Format String Syntax are incorrect or poorly worded

[Raymond Hettinger]

Raymond Hettinger added the comment:

I think all of these read fine as-is though I would change "argument first" to  
"first argument" or just "argument".   Adding the word "positional" is a 
distractor from what the comments are trying to communicate.

The version numbering is normally done with a directive and outside of the 
examples.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Compression of random binary data

[Joonas Liik]

On 11 July 2016 at 20:52,   wrote:
> What kind of statistic law or mathematical conjecture  or is it even a 
> physical law is violated by compression of random binary data?
>
> I only know that Shanon theorised it could not be done, but were there any 
> proof?

Compression relies on some items in the dataset being more frequent
than others, if you have some dataset that is completely random it
would be hard to compress as most items have very similar number of
occurrances.

> What is to say that you can not do it if the symbolic representation is 
> richer than the symbolic represenatation of the dataset.
>
> Isn't it a fact that the set of squareroots actually depict numbers in a 
> shorter way than their actual representation.

A square root may be smaller numerically than a number but it
definitely is not smaller in terms of entropy.

lets try to compress the number 2 for instance using square roots.
sqrt(2) = 1.4142
the square root actually takes more space in this case even tho it is
a smaller number. so having the square root would have negative
compression in this case.
with some rounding back and forth we can probably get around the fact
that sqrt(2) would take an infinite amout of memory to accurately
represent but that neccesarily means restricting the values we are
possible of encoding.

for sqrt(2) to not have worse space consumprion than the number 2
itself we basically have to trow away precision so sqrt(2) ~= 1
now i challenge you to get that 2 back out of that 1..
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27464] Document that SplitResult & friends are namedtuples

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee: docs@python -> rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27485] urllib.splitport -- is it official or not?

[Guido van Rossum]

New submission from Guido van Rossum:

I've seen and written some code that uses urllib.splitport() [1], but it's not 
in the export list, nor in the docs. However I see no easy other way to perform 
the same function. Should we make it official, or get rid of it? It's used 
internally in urllib/request.py [2]. There's a test for it in test_urlparse.py 
[3], but another test [4] also acknowledges that it's "undocumented" (which 
suggests that the author of that test didn't know what to do with it either).

Same question for the others in that list [4]:
'splitattr', 'splithost', 'splitnport', 'splitpasswd',
'splitport', 'splitquery', 'splittag', 'splittype', 'splituser',
'splitvalue',
'Quoter', 'ResultBase', 'clear_cache', 'to_bytes', 'unwrap',

References:
[1] https://hg.python.org/cpython/file/tip/Lib/urllib/parse.py#l956
[2] https://hg.python.org/cpython/file/tip/Lib/urllib/request.py#l106
[3] https://hg.python.org/cpython/file/tip/Lib/test/test_urlparse.py#l1015
[4] https://hg.python.org/cpython/file/tip/Lib/test/test_urlparse.py#l946

--
messages: 270193
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: urllib.splitport -- is it official or not?
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Compression of random binary data

[jonas . thornvall]

What kind of statistic law or mathematical conjecture  or is it even a physical 
law is violated by compression of random binary data? 

I only know that Shanon theorised it could not be done, but were there any 
proof? 

What is to say that you can not do it if the symbolic representation is richer 
than the symbolic represenatation of the dataset. 

Isn't it a fact that the set of squareroots actually depict numbers in a 
shorter way than their actual representation. 

Now the inpretator or program must know the rules. And i have very good rules 
to make it happen. 
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27483] Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c

[Maciej Fijalkowski]

Maciej Fijalkowski added the comment:

On windows the profiler runs in a separate thread and pauses/restarts other 
threads (hence the requirements are slightly different). HEAD_LOCK etc. are def 
not async-signal safe, but it's not an issue on linux

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Touch screen development in Python

[Jahn]

Hi ,
Does anyone use Python for  developping  applications that  work with a touch 
screen?


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

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

[issue27469] Unicode filename gets crippled on Windows when drag and drop

[Steve Dower]

Steve Dower added the comment:

I don't want Python to get into the business of changing the command line.

I've started looking into building the shell extension so we can pass through 
arguments correctly. Once we have this, there are likely other features we can 
add to it (maybe extract __author__/__version__ and display it in tooltips? 
Certainly some of the requests for IDLE could be accommodated).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Curious Omission In New-Style Formats

[Ethan Furman]

On 07/11/2016 09:28 AM, Steven D'Aprano wrote:

On Tue, 12 Jul 2016 01:04 am, Ian Kelly wrote:



Er, what? I count *five* digits in "00123", not three.

You seem to be assuming that "precision" can only refer to digits after the
decimal place, but that's a dubious proposition.


I will readily admit to not having a maths degree, and so of course to 
me saying the integer 123 has a precision of 5, 10, or 99 digits seems 
like hogwash to me.


But I'm always willing to learn.  So please explain what 123 with a 
precision of five integer digits means, and what to do we gain by saying 
such a thing?


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

[issue27483] Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c

[STINNER Victor]

STINNER Victor added the comment:

Is the profiler running in the same process than the profiled application?

Vmprof uses a signal handler, right? HEAD_LOCK is a mutex, acquire a mutex
is not async-signal safe :-( Is it an issue?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27484] Some Examples in Format String Syntax are incorrect or poorly worded

[Rufus V. Smith]

New submission from Rufus V. Smith:

In section 6.1.3 Format String Syntax, some examples have incorrect or poorly 
worded comments:

Original:

"Harold's a clever {0!s}"# Calls str() on the argument first
"Bring out the holy {name!r}"# Calls repr() on the argument first
"More {!a}"  # Calls ascii() on the argument first

Suggested Changes:

"Harold's a clever {0!s}"# Calls str() on first positional argument
"Bring out the holy {name!r}"# Calls repr() on the named argument 'name'
"More {!a}"  # Calls ascii() on first positional argument 
(v. 3.1 and later)

--
assignee: docs@python
components: Documentation
messages: 270189
nosy: RufusVS, docs@python
priority: normal
severity: normal
status: open
title: Some Examples in Format String Syntax are incorrect or poorly worded

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27483] Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c

[Maciej Fijalkowski]

New submission from Maciej Fijalkowski:

Hi

The use case here is for C-based statistical profilers. When running vmprof on 
linux/os x, you can get the current thread state from 
PyThreadState_GetUnchecked or a similar solution. However, on windows you need 
to walk all the interpreter state, for which there is an API. However that API 
is only ever used with locks (HEAD_LOCK/HEAD_UNLOCK), which are not exposed, 
which turns API mostly useless.

--
messages: 270188
nosy: fijall, haypo
priority: normal
severity: normal
status: open
title: Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Curious Omission In New-Style Formats

[Steven D'Aprano]

On Tue, 12 Jul 2016 01:04 am, Ian Kelly wrote:

> On Sun, Jul 10, 2016 at 6:34 PM, Lawrence D’Oliveiro
>  wrote:
>> On Sunday, July 10, 2016 at 7:22:42 PM UTC+12, Ian wrote:
>>> On Sat, Jul 9, 2016 at 11:54 PM, Lawrence D’Oliveiro wrote:
 In printf-style formats, you can specify the number of digits for an
 integer separately from the field width. E.g.

 >>> "%#0.5x" % 0x123
 '0x00123'

>>> except perhaps that precision doesn't really make sense for integers
>>> in the first place.
>>
>> Except that it does make sense, as I showed in my example.
> 
> Your example showed a 3-digit number being formatted with a requested
> precision of 5 digits. The way this was done was by left-padding the
> number with 0s until there were 5 digits, 

Right.

> but still only 3 digits of precision.

Er, what? I count *five* digits in "00123", not three.

You seem to be assuming that "precision" can only refer to digits after the
decimal place, but that's a dubious proposition. That might be the way
printf interprets the precision for *floats*, but its not the way it
interprets the precision for *ints*, and who is to say that one way is
right and the other is wrong?


> If you truly wanted to format the number with a precision 
> of 5 digits, it would look like this:
> 
> 0x123.00

Er, no, because its an integer.

Now, if I remember what I was told in my physics class circa 1985 correctly:

12345678 written with a precision of five digits is 12346000;

12345678 written with a precision of five decimal places is 12345678.0.

How should we extrapolate to the case where the precision *in digits* is
greater than the number of digits available? Well, for the "decimal places"
case, we add zeroes to the right. So for the digits case, we ought to add
zeroes to the left, which brings us back to the printf usage:

123 with five digits of precision is "00123".


And we can combine that with the overall length to pad the result with
spaces as well.

It seems to me that it would be reasonable to support this for format() too.


> It may happen to do what you want in the printf-style format, but
> calling the field "precision" is at best misleading, and there are
> other ways to accomplish the same result.

Naturally. So why bother to have .format() or % in the first place? There's
always other ways to accomplish the same result.





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

[issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12

[R. David Murray]

R. David Murray added the comment:

Now you see why I guessed that it was a Gentoo issue :)  Or an issue in 
whatever it is you are using, since it doesn't sound like vanilla gentoo, 
either.

So, I'm closing this again.  If you find something you really think is a bug in 
*our* build process, you can open a new ticket for it.

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12

[Martin Mokrejs]

Changes by Martin Mokrejs :


Added file: http://bugs.python.org/file43693/nohup-gentoo-prefix.out

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27480] Cannot link _crypt and _nis modules on a host with glibc-2.12

[Martin Mokrejs]

Martin Mokrejs added the comment:

Interesting, using the system-wide RedHat stuff I can compile vanilla 
Python-3.4.5. See attached nohup.out. I tried to stick to the same configure 
arguments as Gentoo's package manager used.

I also tried to compile the vanilla tarball under Gentoo::Prefix and wow, it 
also went through (as fat as _crypt is concerned). See nohup-gentoo-prefix.out

--
Added file: http://bugs.python.org/file43692/nohup.out

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com