Re: Simple graphic library for beginners

[Michael Torrie]

On 01/11/2018 11:48 PM, Jan Erik Moström wrote:
> On 10 Jan 2018, at 13:40, Jan Erik Moström wrote:
> 
>> I'm looking for a really easy to use graphic library. The target users 
>> are teachers who have never programmed before and is taking a first 
>> (and possible last) programming course.
> 
> Thanks for all the suggestions, I'm going to take a look at them and see 
> what fits my requirements best.

I'm glad you are willing to overlook all the noise in this thread!  Good
luck and let us know what path you end up taking.

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

[issue32543] odd floor division behavior

[Tim Peters]

Tim Peters  added the comment:

This report appears to be the same:

https://bugs.python.org/issue27463

One other thing to note:  the Python docs are sometimes unclear about whether 
expressions are intended to be interpreted as Python code or as mathematical 
expressions.  In:

"""
floor division will be implemented in all the Python numeric types, and will 
have the semantics of:

a // b == floor(a/b)
"""

note that it did _not_ say `math.floor(a/b)`.  `floor(a/b)` here is intended to 
be read as a mathematical (infinitely precise) specification.  As can be 
inferred from the output Serhiy posted, after the Python

a = 0.9
b = 0.1

the infinitely precise value of `a/b` is a tiny bit less than 9, so the 
infinitely precise value of `floor(a/b)` is exactly 8.  Which is what the 
Python `a // b` returns.

Personally, I wish Python 3 had changed the meaning of `//` (and `divmod()` and 
`%` - the three are deeply related) for floats, but too late for that now :-)

--

___
Python tracker 

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

[issue32146] multiprocessing freeze_support needed outside win32

[bbayles]

bbayles  added the comment:

I ran into this issue, and found references to it on StackOverflow [1] and 
GitHub [2] as well. I found that the problem applies to both the 'spawn' and 
'forkserver' start methods on Linux.

I made an attempt to implement dancol's fix above. (1) and (3) are 
straightforward, but if there's an elegant way to do the "tickle" in (2) I 
wasn't able to figure it out?

My branch [3] has something that seems to work with the 'spawn' method and 
cx_Freeze. Perhaps someone could look at that and tell me if I'm on a 
reasonable track? If so, I can attempt to extend the method to cover 
'forkserver' as well.

[1] https://stackoverflow.com/q/47325297/353839

[2] https://github.com/anthony-tuininga/cx_Freeze/issues/264

[3] 
https://github.com/python/cpython/compare/master...bbayles:bpo-32146-freeze_support

--
nosy: +bbayles

___
Python tracker 

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

[issue32502] uuid1() fails if only 64-bit interface addresses are available

[Andres Petralli]

Andres Petralli  added the comment:

Re: rarity. There is at least one more person that ran into the same issue as 
seen in this report: https://github.com/Azure/azure-cli/issues/5184

--

___
Python tracker 

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

[issue32502] uuid1() fails if only 64-bit interface addresses are available

[Andres Petralli]

Andres Petralli  added the comment:

Moving doesn't work, but even removing the firewire adapter (which was unused 
on my system), doesn't remove it from the output of ifconfig.

I did however work around the issue by just patching up uuid in a suboptimal 
manner (truncated the 64bit int to 48bit).

A proper fix would probably need to discard EUI-64 addresses and look for 
EUI-48 specifically.

--

___
Python tracker 

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

[issue32502] uuid1() fails if only 64-bit interface addresses are available

[Ned Deily]

Ned Deily  added the comment:

(As a workaround, you *might* be able to reorder the network interfaces in the 
System Preferences -> Network control panel.)

--

___
Python tracker 

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

[issue29240] PEP 540: Add a new UTF-8 mode

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +5024

___
Python tracker 

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

[issue32502] uuid1() fails if only 64-bit interface addresses are available

[Andres Petralli]

Andres Petralli  added the comment:

This could be purely incidental to have shown up in 10.13, but yes, the problem 
comes from the fact that the first hardware ID in the list of devices happens 
to be an EUI-64 address with 64 bits now. This is the Firewire interface of my 
Mac Pro and maybe one of the few that actually uses a EUI-64 addresses, hence 
relatively rare. Maybe the order changed in 10.13 and this now happens to be 
the first entry returned from 'ifconfig' when previously maybe it was the 
Ethernet adapter, but given the lookup algorithm in uuid reads in line by line 
until it finds the first hw id, this is bound to fail on my machine. Clearly, I 
don't think uuid should make assumptions about order of interfaces that could 
have mixed EUI-48 and EUI-64 addresses.

--

___
Python tracker 

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

[issue32543] odd floor division behavior

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

This is the result of multiple roundings.

0.9 and 0.1 can't be represented exactly as floats. They are approximated by 
binary fractions.

>>> from fractions import Fraction
>>> Fraction(0.9)
Fraction(8106479329266893, 9007199254740992)
>>> Fraction(0.1)
Fraction(3602879701896397, 36028797018963968)

The result of the division of these fractions can't be represented as a float 
too.

>>> Fraction(0.9)/Fraction(0.1)
Fraction(32425917317067572, 3602879701896397)
>>> Fraction(0.9)/Fraction(0.1) - 9
Fraction(-1, 3602879701896397)
>>> float(Fraction(0.9)/Fraction(0.1) - 9)
-2.7755575615628914e-16
>>> 9 + float(Fraction(0.9)/Fraction(0.1) - 9)
9.0

It is slightly smaller than 9, but the nearest float value is 9.0. Thus the 
result of the division is rounded up to 9.0.

A similar issue already was opened several months ago. I don't remember the 
number.

--
nosy: +serhiy.storchaka
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

[issue32543] odd floor division behavior

[Ammar Askar]

Ammar Askar  added the comment:

Looks like floor division for floats call into the divmod function, which has 
the same behavior:

>>> 0.9 .__divmod__(0.1)
(8.0, 0.09998)

--
nosy: +ammar2

___
Python tracker 

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

[issue32543] odd floor division behavior

[Steven D'Aprano]

Steven D'Aprano  added the comment:

That does look at first glance like a bug in // to me. 0.9/0.1 is correctly 
rounded to 9.0 exactly, so flooring it should return 9 (as it does):

# Python 3.5 on Linux
py> 0.9/0.1 == 9
True
py> math.floor(0.9/0.1)
9

So I too would expect that 0.9//0.1 should evaluate as 9, not 8.

--
nosy: +mark.dickinson, steven.daprano, tim.peters

___
Python tracker 

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

[issue32537] multiprocessing.pool.Pool.starmap_async - wrong parameter name

[Ned Deily]

Ned Deily  added the comment:

This wouldn't qualify as a security problem so, if the problem no longer exists 
in 3.6, then this issue should be closed

--
nosy: +ned.deily

___
Python tracker 

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

[issue32537] multiprocessing.pool.Pool.starmap_async - wrong parameter name

[Martin Panter]

Martin Panter  added the comment:

This was supposed to be fixed in 3.6+ by Issue 31304. In general, 3.5 only gets 
security fixes at this stage. I’m not sure if it is easy or worth back porting 
this.

--
nosy: +martin.panter

___
Python tracker 

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

[issue32502] uuid1() fails if only 64-bit interface addresses are available

[Ned Deily]

Ned Deily  added the comment:

Thanks for your additional analysis.  So, assuming I understand it correctly, 
the problem here is that there can be hardware configurations where the only 
(or first?) hardware addresses available exceed 48 bits.  I'm not sure what 
might be different for your system when running 10.13, assuming uuid1() used to 
work on earlier versions of macOS; perhaps another network interface with a 
smaller address was supported and configured?  It seems like such 
configurations are pretty rare; there don't seem to be any prior bug reports on 
this and it would be unusual for Mac systems to only have a Firewire 
(non-loopback) network interface configured.  In any case, such configurations 
presumably are not limited to Macs so I'm removing the macOS tag.

--
components: +Library (Lib) -macOS
nosy:  -ronaldoussoren
stage:  -> needs patch
title: uuid1() broken on macos high sierra -> uuid1() fails if only 64-bit 
interface addresses are available

___
Python tracker 

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

[issue32248] Port importlib_resources (module and ABC) to Python 3.7

[Brett Cannon]

Brett Cannon  added the comment:


New changeset bca42186b69e2e615d29d0d4fdb493c9fe71c48b by Brett Cannon in 
branch 'master':
bpo-32248: Introduce the concept of Loader.get_resource_reader() (GH-5108)
https://github.com/python/cpython/commit/bca42186b69e2e615d29d0d4fdb493c9fe71c48b


--

___
Python tracker 

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

[issue32542] memory not freed, aka memory leak continues...

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Issue25582 fixed a memory leak. If run the tests repeatedly every iteration 
leaked 100 MB of memory. If you get a MemoryError with a single iteration, this 
means that your machine just doesn't have enough memory for tests. Tests 
require around 500-600MB of memory on 32-bit platform.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue32543] odd floor division behavior

[Nathan Goldbaum]

New submission from Nathan Goldbaum :

According to PEP 238:


"floor division will be implemented in all the Python numeric types, and will 
have the semantics of:

a // b == floor(a/b)

except that the result type will be the common type into which a and b are 
coerced before the operation."

But consider the following cases in Python 3.6.3:

>>> 0.9//0.1
8.0
>>> 0.8//0.1
8.0
>>> import math
>>> math.floor(0.9/0.1)
9
>>> math.floor(0.8/0.1)
8

Am I missing something?

--
components: Interpreter Core
messages: 309873
nosy: Nathan.Goldbaum
priority: normal
severity: normal
status: open
title: odd floor division behavior
type: behavior
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

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> 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

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 5b76bdba071e7bbd9fda0b9b100d1506d95c04bd by Serhiy Storchaka in 
branch 'master':
bpo-31993: Do not use memoryview when pickle large strings. (#5154)
https://github.com/python/cpython/commit/5b76bdba071e7bbd9fda0b9b100d1506d95c04bd


--

___
Python tracker 

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

[issue32541] cgi.FieldStorage constructor assumes all lines terminate with \n

[Ned Deily]

Change by Ned Deily :


--
nosy:  -ned.deily

___
Python tracker 

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

[issue32541] cgi.FieldStorage constructor assumes all lines terminate with \n

[Ned Deily]

Ned Deily  added the comment:

I'm removing the macOS tag and nosies because I think it highly unlikely that 
the behavior would be limited to macOS.  Without a reproducible test case, it's 
not easy to verify that or investigate further.  The cgi module doesn't get a 
lot of attention but perhaps someone with cgi experience will take a look.

--
components:  -macOS
nosy:  -ronaldoussoren

___
Python tracker 

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

[issue29708] support reproducible Python builds

[Brett Cannon]

Brett Cannon  added the comment:

A disagreement has popped up over what the ideal solution is on the PR 
currently connected to this issue. I'm having the folks involved switch it over 
to here.

IMO I think py_compile can respect SOURCE_DATE_EPOCH and just blindly use it 
for creating .pyc files. That way builds are reproducible. Yes, it will quite 
possibly lead to those .pyc files being regenerated the instant Python starts 
running, but SOURCE_DATE_EPOCH is entirely about builds, not runtimes. Plus 
.pyc files are just optimizations and so it is not critical they not be 
regenerated again later.

--

___
Python tracker 

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

[issue32542] memory not freed, aka memory leak continues...

[Michael Felt]

New submission from Michael Felt :

in issue25582 - the issue is not (yet) resolved. Perhaps this one can be closed 
and issue25582 reopened.

Both from python2-2.7.14 and "git master" I am getting:

michael@x071:[/data/prj/python/git/gcc-python3-3.7]./python -m unittest -v 
ctypes.test.test_pointers  <
test_abstract (ctypes.test.test_pointers.PointersTestCase) ... ok
test_basic (ctypes.test.test_pointers.PointersTestCase) ... ok
test_basics (ctypes.test.test_pointers.PointersTestCase) ... ok
test_bug_1467852 (ctypes.test.test_pointers.PointersTestCase) ... ok
test_c_void_p (ctypes.test.test_pointers.PointersTestCase) ... ok
test_callbacks_with_pointers (ctypes.test.test_pointers.PointersTestCase) ... ok
test_change_pointers (ctypes.test.test_pointers.PointersTestCase) ... ok
test_charpp (ctypes.test.test_pointers.PointersTestCase)
Test that a character pointer-to-pointer is correctly passed ... ok
test_from_address (ctypes.test.test_pointers.PointersTestCase) ... ok
test_other (ctypes.test.test_pointers.PointersTestCase) ... ok
test_pass_pointers (ctypes.test.test_pointers.PointersTestCase) ... ok
test_pointer_crash (ctypes.test.test_pointers.PointersTestCase) ... ok
test_pointer_type_name (ctypes.test.test_pointers.PointersTestCase) ... ok
test_pointer_type_str_name (ctypes.test.test_pointers.PointersTestCase) ... 
ERROR
test_pointers_bool (ctypes.test.test_pointers.PointersTestCase) ... ok

==
ERROR: test_pointer_type_str_name (ctypes.test.test_pointers.PointersTestCase)
--
Traceback (most recent call last):
  File "/data/prj/python/git/gcc-python3-3.7/Lib/ctypes/test/test_pointers.py", 
line 208, in test_pointer_type_str_name
large_string = 'T' * 2 ** 25
MemoryError

--
Ran 15 tests in 0.319s

FAILED (errors=1)

+
Looking at the test source:

  +196  def test_pointer_type_name(self):
  +197  LargeNamedType = type('T' * 2 ** 25, (Structure,), {})
  +198  self.assertTrue(POINTER(LargeNamedType))
  +199
  +200  # to not leak references, we must clean _pointer_type_cache
  +201  from ctypes import _pointer_type_cache
  +202  del _pointer_type_cache[LargeNamedType]
  +203
  +204  def test_pointer_type_str_name(self):
  +205  large_string = 'T' * 2 ** 25
  +206  P = POINTER(large_string)
  +207  self.assertTrue(P)
  +208
  +209  # to not leak references, we must clean _pointer_type_cache
  +210  from ctypes import _pointer_type_cache
  +211  del _pointer_type_cache[id(P)]


After changing the exponent (** 25) to "** 23" on either line 197 OR 205 
- ALL test succeed -
After changing the exponent to " ** 24" on BOTH lines 197 and 205, all tests 
pass.


My concern is that the "patch" from issue 25582 the 
"del _pointer_type_cache[]" statement is not freeing memory.

+
What can I add to the test to debug!
+
p.s. - results are the same on AIX (5.3 and 6.1) Python2-2.7.14 and 
Pyhton3-3.7.X (git master). Compiler does not seem to matter (both xlc and gcc).
32-bit, default memory model (256 MByte max - aka (2 ** 28) for data and 
malloc. I could also try changing the memory model - but will do that only if 
the test, by definition, is not "free()ing" the memory used, when done.

HTH
Michael

--
components: Tests
messages: 309869
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: memory not freed, aka memory leak continues...
type: behavior
versions: Python 2.7, Python 3.7

___
Python tracker 

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

[issue32541] cgi.FieldStorage constructor assumes all lines terminate with \n

[Ian Craggs]

New submission from Ian Craggs :

Using cgi.FieldStorage in an HTTP server in a subclass of 
BaseHTTPRequestHandler, parsing the request with:

form = cgi.FieldStorage(fp=self.rfile,
headers=self.headers,
environ={"REQUEST_METHOD":op.upper(),
  "CONTENT_TYPE":self.headers['Content-Type'],})

This has been working fine with clients using the Python requests library. Now 
processing requests from a Java library 
(org.apache.cxf.jaxrs.client.WebClient), the final line in a multipart request 
does not include the (\r)\n, which causes the final read to hang until a socket 
timeout.  The read in question is in cgi.py, read_lines_to_outerboundary:

line = self.fp.readline(1<<16) # bytes

(line 824 in Python 3.6.2).  I changed this read to not assume the termination 
of the final line with \n:

def read_line(self, last_boundary):
line = self.fp.readline(len(last_boundary))
if line != last_boundary and not line.endswith(b"\n"):
line += self.fp.readline((1<<16) - len(last_boundary))
return line


and the request worked.  The Java library is being used in tests against our 
production web server so I assume that is working correctly.  

Perhaps I am misusing the FieldStorage class, I don't know, I'm not expert on 
this.

--
components: Library (Lib), macOS
messages: 309868
nosy: Ian Craggs, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: cgi.FieldStorage constructor assumes all lines terminate with \n
type: behavior
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

[issue32476] Add concat functionality to ElementTree xpath find

[John Jolly]

Change by John Jolly :


--
nosy: +eli.bendersky

___
Python tracker 

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

[issue32540] venv docs - doesn't match behavior

[Jason R. Coombs]

New submission from Jason R. Coombs :

In the docs for the venv command, it states:

> Changed in version 3.4: In earlier versions, if the target directory already 
> existed, an error was raised, unless the --clear or --upgrade option was 
> provided. Now, if an existing directory is specified, its contents are 
> removed and the directory is processed as if it had been newly created.

However, that's not the behavior I observe:

$ python -m venv env
$ env/bin/pip install -q requests
$ python -m venv env  
$ env/bin/python -c "import requests"
$

Plus, I believe the _current_ behavior should be documented not in a 'change' 
note. I suggest the change note should read:

> Changed in version 3.4: In earlier versions, if the target directory already 
> existed, an error was raised, unless the --clear or --upgrade option was 
> provided.

And the third paragraph, following "It also creates an (initially 
empty...Lib\site-packages).":

> If an existing directory is specified, it will be re-used.

--
assignee: docs@python
components: Documentation
messages: 309867
nosy: docs@python, jason.coombs
priority: normal
severity: normal
status: open
title: venv docs - doesn't match behavior

___
Python tracker 

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

Re: Simple graphic library for beginners

[Paul Moore]

On 12 January 2018 at 17:25, Mikhail V  wrote:
> And the target Python where the package will be installed should be defined by
> a switch, e.g. 'pip -2', 'pip -3' (in analogy with 'py -2', 'py -3').
> The question is though, how pip will know what version(s) of python I have, 
> and
> if I installed them later? Hmm, not an easy problem. So in this case pip shoud
> track the multiple versions each time I install another version of python.

If that's how you want it to behave, just use "py -2 -m pip" or "py -3
-m pip" or "py -3.6 -m pip" as required. Works now, no hassle. You
still have to install pip (the package, not the executable) in each
Python home, but that's just how Python packages work (and pip is
already installed by default when you install Python on Windows
anyway).

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

[issue32539] os.listdir(...) on deep path on windows in python2.7 fails with errno 123

[Eryk Sun]

Change by Eryk Sun :


--
stage:  -> patch review
type:  -> behavior

___
Python tracker 

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

[issue32539] os.listdir(...) on deep path on windows in python2.7 fails with errno 123

[Eryk Sun]

Eryk Sun  added the comment:

This should be fixed. That said, we have to use a unicode string for a long 
path anyway. Prior to Windows 8, the conversion from ANSI to Unicode in the 
system runtime library uses a static MAX_PATH buffer, so the ANSI API is 
inherently limited to MAX_PATH. You'll see this in the documentation of all 
functions that allow using \\?\ extended paths:

In the ANSI version of this function, the name is limited to 
MAX_PATH characters. To extend this limit to 32,767 wide 
characters, call the Unicode version of the function and 
prepend "\\?\" to the path.

Decoding ANSI strings uses a dynamically-sized buffer in Windows 8, but the 
change is undocumented and should not be relied upon.

Unfortunately, we can't reliably use a raw unicode string literal in Python 2, 
since \u and \U escapes are still evaluated. We can instead use forward slashes 
and normalize via os.path.normpath.

--
nosy: +eryksun
stage: patch review -> 

___
Python tracker 

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

Re: Simple graphic library for beginners

[Mikhail V]

On Fri, Jan 12, 2018 at 10:38 AM, Paul Moore  wrote:
> On 12 January 2018 at 06:47, Steven D'Aprano
>  wrote:

>> If pip is joined at the hip to a specific version of Python, I think that
>> we ought to be able to specify the version number like we can with Python.
>>
>> Something like:
>>
>> pip ...  # use whichever version of pip comes first on the PATH
>> pip3.6 ...  # use the pip installed with Python 3.6
>> pip2.7 ...  # use the pip installed with Python 2.7
>
> Well, that's sort of how it's intended to work, but in practice it
> doesn't seem to be as straightforward as it ought to be. I can't
> really say why, as it's a Unix-only thing and I don't really
> understand the reasons, but it's why I'm a fan of the "python -m pip"
> approach. There's discussion on the pip tracker if you're interested
> enough to go searching - I know it's something that's been debated,
> but I don't recall the context.

In general I think more than one app and executable with same name
on a system already asks for problems.
On Windows I had issues with pip and pygame and I have two Pythons -
2.7.14 and 3.6.2.
The problem was that I could not make it install to 2.7, and tried many options,
looking in SO there were so many different solutions, but finally I found
something that reinstalled newer pip, but I don't remember frankly.

My opinion (from Windows user's POV) - I'd prefer if there should be
only one PIP in system,
so running pip will unambigiosly mean that I run (or upgrade) THE pip.
(and not something which I don't
even know where it is located). Ideally also it should be installed in
separate Directory.
So I'd have folders:

python 27
python 36
pip

And the target Python where the package will be installed should be defined by
a switch, e.g. 'pip -2', 'pip -3' (in analogy with 'py -2', 'py -3').
The question is though, how pip will know what version(s) of python I have, and
if I installed them later? Hmm, not an easy problem. So in this case pip shoud
track the multiple versions each time I install another version of python.


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

[issue32539] os.listdir(...) on deep path on windows in python2.7 fails with errno 123

[Anthony Sottile]

Change by Anthony Sottile :


--
keywords: +patch
pull_requests: +5023
stage:  -> patch review

___
Python tracker 

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

[issue28914] selectmodule build fails

[Chris Rose]

Chris Rose  added the comment:

Ach; ignore the libc version below; that's a PEBKAC error on my part. The libc 
version on the system that's failing is older (and hard to get; just trust me, 
it's older) and doesn't have the relevant epoll value.

--

___
Python tracker 

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

[issue28914] selectmodule build fails

[Chris Rose]

Chris Rose  added the comment:

Is this patch mergeable? I'm trialing the 3.7.0a4 build on some systems here 
and am unable to build due to this issue, on libc 2.12:

± /lib/libc.so.6
GNU C Library stable release version 2.12, by Roland McGrath et al.
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.6 20110731 .
Compiled on a Linux 3.2.5 system on 2017-10-20.
Available extensions:
The C stubs add-on version 2.1.2.
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
RT using linux kernel aio

--
nosy: +offby1

___
Python tracker 

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

Unfortunately the yp_prot.h and ypclnt.h [0] headers have also moved to a 
different package.

Currently they reside at /usr/include/nsl/rpcsvc/*.h

[0] 
https://github.com/python/cpython/blob/f3031b8a7ad71d3b6ed05da7f3041d9efbe773cf/Modules/nismodule.c#L18
[1] https://fedoraproject.org/wiki/Changes/NISIPv6

--

___
Python tracker 

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

[issue32539] os.listdir(...) on deep path on windows in python2.7 fails with errno 123

[Anthony Sottile]

New submission from Anthony Sottile :

On windows, a deep path can be accessed by prefixing the path with \\?\

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx?f=255=-2147217396#maxpath

The call to `listdir()` fails because it uses a posix separator.

A quick patch to fix this is to use `SEP` here: 
https://github.com/python/cpython/blob/ab95b3074ee43098edf3f23b07fb18ef57ee614d/Modules/posixmodule.c#L2388
 (I can submit a patch for this)

Here's a stacktrace

>>> os.listdir(r'\\?\C:\Temp')
Traceback (most recent call last):
  File "", line 1, in 
WindowsError: [Error 123] The filename, directory name, or volume label syntax 
is incorrect: '?\\C:\\Temp/*.*'


This works fine in python3, as the code has been refactored to use `SEP` 
already.

>>> os.listdir(r'\\?\C:\Temp')
[]

--
components: Library (Lib), Windows
messages: 309862
nosy: Anthony Sottile, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.listdir(...) on deep path on windows in python2.7 fails with errno 123
versions: Python 2.7

___
Python tracker 

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

[issue32528] Change base class for futures.CancelledError

[Joongi Kim]

Change by Joongi Kim :


--
nosy: +achimnol

___
Python tracker 

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

[Christian Heimes]

Christian Heimes  added the comment:


New changeset ab95b3074ee43098edf3f23b07fb18ef57ee614d by Christian Heimes 
(Miss Islington (bot)) in branch '2.7':
bpo-32521: nis libtirpc (GH-5137) (#5166)
https://github.com/python/cpython/commit/ab95b3074ee43098edf3f23b07fb18ef57ee614d


--

___
Python tracker 

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

[Christian Heimes]

Christian Heimes  added the comment:


New changeset d55d6825d7bd0fc120c95d579065623ce6392a2f by Christian Heimes 
(Miss Islington (bot)) in branch '3.6':
[3.6] bpo-32521: nis libtirpc (GH-5137) (#5165)
https://github.com/python/cpython/commit/d55d6825d7bd0fc120c95d579065623ce6392a2f


--

___
Python tracker 

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

Re: Simple graphic library for beginners

[Lele Gaifax]

bartc  writes:

> If you a beginner, outsider, or infrequent user of Python with no idea of
> what the latest version is, except that you already have 3.6 but it might
> have a problem, which would you choose?

Unless you are also unable to read *and* understand, by any chance you'd
follow the very first link related to 3.7, and seeing "This is an early
developer preview of Python 3.7" you could *decide* if that's appropriate for
your goal.

But it seems you belong to yet a different category of people indeed, who
blindly follows the "I'm feeling lucky" Google advices.

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it  | -- Fortunato Depero, 1929.

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

[issue30537] Using PyNumber_AsSsize_t in itertools.islice

[Erik Bray]

Erik Bray  added the comment:

> Users might be better off by not seeing an unhelpful error message when 
> passing in a numpy.int32, or they might be worse-off by having lost a cue 
> that they were writing inefficient code (which invisibly creates temporary 
> integer objects on every call when presumably the whole reason for using 
> numpy was a concern for efficiency).

While it's true there are many Numpy users who don't understand what they're 
doing, any time they go into the Python interpreter they're losing the benefits 
of Numpy anyways (which are fast vectorized operations on arrays).

--
nosy: +erik.bray

___
Python tracker 

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

[issue32538] Multiprocessing Manager on 3D list - no change of the list possible

[Johannes]

New submission from Johannes :

I have the following code, which works without multiprocessing:

data=[[['','','','','','','','','','','','']]]
data[0][0][0] = 5
data[0][0][1] = "5" # data in the array is mixed with float and str
print(data)

#=> [[[5, '5', '', '', '', '', '', '', '', '', '', '']]]

Now I want to use Multiprocessing and every process should be able to change 
the 3D list. This doesn't work and no error message is shown.

from multiprocessing import Process, Manager
manager=Manager()
data=manager.list([[['','','','','','','','','','','','']]])
data[0][0][0] = 5
data[0][0][1] = "5"
print(data)

#=> [[['', '', '', '', '', '', '', '', '', '', '', '']]]

I found the following text:

list(sequence)
Create a shared list object and return a proxy for it.
Changed in version 3.6: Shared objects are capable of being nested. For 
example, a shared container object such as a shared list can contain 
other shared objects which will all be managed and synchronized by the 
SyncManager.(https://docs.python.org/3/library/multiprocessing.html)

Unfortunately it also doesn't work with 3.6.3, same problem as before! But as 
it should work, I guess it's a bug?

I use Ubuntu 16.04...

--
components: Interpreter Core
messages: 309858
nosy: John_81
priority: normal
severity: normal
status: open
title: Multiprocessing Manager on 3D list - no change of the list possible
type: behavior
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: Simple graphic library for beginners

[bartc]

On 12/01/2018 01:56, Chris Angelico wrote:

On Fri, Jan 12, 2018 at 12:21 PM, bartc  wrote:

On 11/01/2018 23:23, Chris Angelico wrote:


On Fri, Jan 12, 2018 at 10:11 AM, bartc  wrote:




I'm almost ready to plonk you, but I think there is still SOME value
in your posts. But please, stop denigrating what you don't understand.



And please try to see things from the pointer of view of a beginner or
outsider, where anything to do with Python seems to have a bewildering and
conflicting array of solutions.


You mean the sort of person who goes to the front page


The front page of what?

 and sees just

two options, 2.7 and 3.6, and won't see anything about 3.7 until it's
released?


Google for 'download python windows'. The first hit is this site:

 https://www.python.org/downloads/windows/

But before you click on it, the google search summary includes two links 
in big type, to 2.7.14 and 3.7.0a2 (which are to information not 
downloads). That is a strong suggestion that those are the latest versions.


When you do go to that page, you are looking for a link that has 
'download' next to it. The first 6 such links on the page are all for 3.7.


If you a beginner, outsider, or infrequent user of Python with no idea 
of what the latest version is, except that you already have 3.6 but it 
might have a problem, which would you choose?



Again, a number of people have put in a lot of hours to make
that easy.


It appears that because of that I'm not allowed to make any 
observations, not ones that could be construed as criticism.


But as another example, search for 'download pelles c', the first hit 
should be this page:


  http://www.pellesc.de/index.php?lang=en=download

That I think is a better presentation than Python's. It's also clearer 
which is 32-bit and which is 64. (Will a beginner programmer who's not 
going to be coding low level really appreciate the difference between 
x86 and x86-64?)


But here's another example that goes the other way; the first hit for 
'download lua windows' is this:


  https://www.lua.org/download.html

A rather puzzling page with some gobbledygook on it that appears to do 
with Linux. And the download link gives a list of tar.gz files; not very 
useful.


The second hit isn't much more use; the third one is more promising.

I do get the impression that applications that originate on Windows are 
generally more accessible.


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

[issue32537] multiprocessing.pool.Pool.starmap_async - wrong parameter name

[Tilman Beck]

New submission from Tilman Beck :

The optional parameter for the error callback function is named 
"error_callback" not "error_back"

--
assignee: docs@python
components: Documentation
files: bug.png
messages: 309857
nosy: devnull, docs@python
priority: normal
severity: normal
status: open
title: multiprocessing.pool.Pool.starmap_async - wrong parameter name
versions: Python 3.5
Added file: https://bugs.python.org/file47381/bug.png

___
Python tracker 

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +5022

___
Python tracker 

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

[Christian Heimes]

Christian Heimes  added the comment:


New changeset f3031b8a7ad71d3b6ed05da7f3041d9efbe773cf by Christian Heimes in 
branch 'master':
bpo-32521: nis libtirpc (#5137)
https://github.com/python/cpython/commit/f3031b8a7ad71d3b6ed05da7f3041d9efbe773cf


--

___
Python tracker 

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +5021
stage:  -> patch review

___
Python tracker 

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

[issue19431] Document PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError()

[João Sebastião de Oliveira Bueno]

João Sebastião de Oliveira Bueno  added the comment:

This discussion is fresh, so maybe it is worth asking here prior to 
python-ideas:

In Python we can change any global variable, object attribute or mapping-value 
with function calls. Locals and nonlocals are the only exceptions and from time 
to time that gets in the way of clever oneliners, and it is just plain 
asymmetric. 

What do you say of adding a wrapper to this as an oficial Python function in 
the stdlib? Maybe inspect.setlocal() that could set f_locals and call this?? 
That would  provide a workaround to the asymmetry that locals currently 
experiment. 

It would not impose any extra security risks, since this can be called via 
ctypes already, and also it is not any more subject to abuse than setattr or 
globals()[...] =  can already be abused.

--
nosy: +João.Sebastião.de.Oliveira.Bueno

___
Python tracker 

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

[issue30537] Using PyNumber_AsSsize_t in itertools.islice

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

Just to note that this bug affects SageMath too: 
https://trac.sagemath.org/ticket/24528

Thanks for fixing!

--
nosy: +jdemeyer

___
Python tracker 

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

[issue31804] multiprocessing calls flush on sys.stdout at exit even if it is None (pythonw)

[Pox TheGreat]

Pox TheGreat  added the comment:

I have already uploaded a patch file but it is not in the required format. Also 
I realize that most of the confusion was because I forgot to provide the OS 
version. Perhaps it would be good to have a separate field for that.

I will upload a patch as it is described in the developer guide.

--
type: crash -> behavior

___
Python tracker 

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

[issue32536] ast and tokenize disagree about line number

[Mark Shannon]

New submission from Mark Shannon :

This occurs (on linux at least) when the the end of line sequence `\r\r\n` 
occurs in a comment that is indented relative to the following lines.

The attached file demonstrates the problem.

--
components: Library (Lib)
files: tokenize_fail_test.py
messages: 309852
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: ast and tokenize disagree about line number
type: behavior
versions: Python 2.7
Added file: https://bugs.python.org/file47380/tokenize_fail_test.py

___
Python tracker 

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

Re: merits of Lisp vs Python

[a2htray . yuen]

在 2006年12月8日星期五 UTC+8下午7:07:09，Mark Tarver写道：
> How do you compare Python to Lisp?  What specific advantages do you
> think that one has over the other?
> 
> Note I'm not a Python person and I have no axes to grind here.  This is
> just a question for my general education.
> 
> Mark

12 years ago.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Simple graphic library for beginners

[breamoreboy]

On Friday, January 12, 2018 at 6:52:32 AM UTC, Steven D'Aprano wrote:
> On Fri, 12 Jan 2018 12:45:04 +1300, Gregory Ewing wrote:
> 
> > Seems to me it would help if pip were to announce which version of
> > Python it's installing things into. And instead of just saying "not
> > compatible with this version of Python", say "not compatible with Python
> > X.Y.Z". That would make these kinds of problems much easier to diagnose.
> 
> This.
> 
> If pip is joined at the hip to a specific version of Python, I think that 
> we ought to be able to specify the version number like we can with Python.
> 
> Something like:
> 
> pip ...  # use whichever version of pip comes first on the PATH
> pip3.6 ...  # use the pip installed with Python 3.6
> pip2.7 ...  # use the pip installed with Python 2.7

The time machine has struck again.  The scripts directory on Windows always 
gives you three executables.  pip.exe is always one of them, and then (say) 
pip3.exe and pip3.6.exe.

> etc.
> 
> And don't say "use a venv" :-)
> -- 
> Steven D'Aprano

--
Kindest regards.

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

Re: Simple graphic library for beginners

[Chris Angelico]

On Fri, Jan 12, 2018 at 9:00 PM, Paul Moore  wrote:
> On 12 January 2018 at 09:12, Tim Golden  wrote:
>> I think the shame here is that there is a learning opportunity on both
>> sides. As Paul says: by and large, the huge amount of work which the Python
>> Packaging team, especially the pip developers, have put in has paid off.
>> It's now usually possible to say: "pip install XXX" and have it work out of
>> the box for any recentish version of Python on any recentish version of a
>> mainstream OS. Once people understand the basics of using that "interface",
>> many things become simple.
>>
>> Unfortunately, where that *doesn't* work, it probably won't be because of
>> low-hanging fruit: it'll be because of some strange interaction of different
>> versions, odd leftover PATH setups, obscure Windows C Runtime redistribution
>> issues, poor encoding interactions between Python and the Windows console,
>> and so on.
>
> Agreed. The other factor, and in my experience one of the most
> frustrating to deal with, is when people *don't* start with "pip
> install XXX", but instead find some complex process on the web, try
> that, have it fail, and then we have to help them untangle whatever
> mess that might have left for them.

This is particularly common on Windows, where the normal way to get
software is "go look on the web, download something, hope it's the
right thing, and give it free reign to install itself on your
computer". On Linux systems, people tend to be a bit more familiar
with the concept of package managers, so they aren't surprised to
learn that Python has one.

(Of course, there is still the big question of "which package manager
ought I to be using", very much an XKCD 927 situation, but at least
that's easier to ask about. "How did you install Python?" "With
apt-get." "Okay, then use apt-get to install the package." "It's not
in apt's repositories." "No problem, pip it is.")

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

[issue32346] Speed up slot lookup for class creation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Since benchgcclasses.py doesn't creates dunder methods,
cache doesn't have GC-tracked tuples, and ref cycles.

Hmm, you're right, thank you.  I can also reproduce your numbers here (using 
benchgcclasses2.py).  There's definitely an impact.

--

___
Python tracker 

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

[issue32346] Speed up slot lookup for class creation

[INADA Naoki]

INADA Naoki  added the comment:

> Note this is really a worst-case benchmark: lots of classes, no methods, no 
> user data beside the classes.

Since benchgcclasses.py doesn't creates dunder methods,
cache doesn't have GC-tracked tuples, and ref cycles.

benchgcclasses2.py adds three dunder methods:

$ ./python benchgcclasses.py
GC time: 13.0 ms
gc: collecting generation 2...
gc: objects in each generation: 1 0 94942
gc: objects in permanent generation: 0
gc: done, 0.0131s elapsed
RSS:
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
inada-n  29604  0.0  0.1  47052 30692 pts/2S+   20:42   0:00 ./python 
benchgcclasses.py

$ ./python-patched benchgcclasses.py
GC time: 17.2 ms
gc: collecting generation 2...
gc: objects in each generation: 1 0 135220
gc: objects in permanent generation: 0
gc: done, 0.0173s elapsed
RSS:
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
inada-n  29626  0.0  0.2  49880 33464 pts/2S+   20:43   0:00 
./python-patched benchgcclasses.py

--
Added file: https://bugs.python.org/file47379/benchgcclasses2.py

___
Python tracker 

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

[issue32346] Speed up slot lookup for class creation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Serhiy:

> The relative speed up looks nice. But it is just few microseconds per class. 
> You have to create many thousands of classes to gain a significant fraction 
> of second.

This work started with your message in 
https://mail.python.org/pipermail/python-dev/2017-December/151277.html pointing 
out that we shouldn't add tp_ slots because it makes type creation and Python 
initialization slower (*), so I'm a bit surprised that you're now claiming 
speeding up type creation (by up to 3x!) is not important...

(*) To quote:

'''
2. Increased class initialization time. For every class for every slot 
we need to look up corresponding methods in dictionaries of the class 
itself and all its parents (caching doesn't work fine at this stage). 
Significant part of class initialization time is spent on initializing 
slots. This will increase the startup time and the time of creating 
local classes. The relative overhead is more significant in Cython.
'''

--

___
Python tracker 

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

[issue32346] Speed up slot lookup for class creation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is a simple script creating 1 classes (a large number, but perhaps not 
out of sight for a large application importing a lot of libraries (*)).

(*) see the experiment I did in 
https://mail.python.org/pipermail/python-dev/2017-December/151260.html

Before:
$ ./python-orig -I benchgcclasses.py 
GC time: 6.8 ms
RSS:
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
antoine  11248  0.0  0.3  41296 24576 pts/1S+   12:18   0:00 ./python-orig 
-I benchgcclasses.py

After:
$ ./python -I benchgcclasses.py 
GC time: 6.9 ms
RSS:
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
antoine  11097  0.0  0.3  41300 24740 pts/1S+   12:18   0:00 ./python -I 
benchgcclasses.py


RSS is a bit unstable from run to run, but roughly the patch seems to add 100 
to 200KB in this case.

As for full GC time, it is quite stable and there's a 0.1ms increase with the 
patch.

Note this is really a worst-case benchmark: lots of classes, no methods, no 
user data beside the classes.

--
Added file: https://bugs.python.org/file47378/benchgcclasses.py

___
Python tracker 

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

Re: Generating SVG from turtle graphics

[Thomas Jollans]

On 2018-01-11 12:03, Steven D'Aprano wrote:
> I'd like to draw something with turtle, then generate a SVG file from it.
> 
> Is this possible?
> 
> If not, is there something I can do which lets me plot lines, shapes and 
> curves and output to SVG?
> 
> Ideally, I'd like to draw a figure pixel by pixel, and then have the SVG 
> library fit a bezier curve to it.
> 

You *could* use matplotlib, which can export to SVG.

Of course, the API is far from ideal for drawing arbitrary shapes --
though it's naturally quite good with lines.

There are some helpful examples in the docs:

https://matplotlib.org/examples/
https://matplotlib.org/examples/shapes_and_collections/index.html

https://matplotlib.org/api/patches_api.html
https://matplotlib.org/api/pyplot_summary.html
... and so on ...


I just played around with it for a few minutes to get a feel for how
much boilerplate you need -

###

from matplotlib import pyplot as plt
from matplotlib.patches import Circle, Rectangle
import numpy as np

ax = plt.gca()
ax.set_ylim([-2, 2])
ax.set_xlim([-2, 2])
ax.set_aspect('equal')
plt.axis('off')

circle = Circle([0,0], 1, fc='red', ec='none')
halfdiag = np.sqrt(0.5)
rect = Rectangle([-halfdiag, -halfdiag],
 2*halfdiag, 2*halfdiag,
 fc='yellow', ec='none')

ax.add_patch(circle)
ax.add_patch(rect)

plt.savefig('/tmp/test.svg')

###

- and this gave a reasonable-looking SVG -

###


http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd;>

http://www.w3.org/2000/svg;
xmlns:xlink="http://www.w3.org/1999/xlink;>
 
  
*{stroke-linecap:butt;stroke-linejoin:round;}
  
 
 
  
   
  
  
   

   
   

   
  
 
 
  
   
  
 

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

[issue32473] Readibility of ABCMeta._dump_registry()

[INADA Naoki]

Change by INADA Naoki :


--
resolution:  -> fixed
stage: patch review -> 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

[issue32473] Readibility of ABCMeta._dump_registry()

[INADA Naoki]

INADA Naoki  added the comment:


New changeset a91662affeb0aae2515cdc5e8f82269337105bf4 by INADA Naoki (Miss 
Islington (bot)) in branch '3.6':
bpo-32473: Improve ABCMeta._dump_registry() readability (GH-5091)
https://github.com/python/cpython/commit/a91662affeb0aae2515cdc5e8f82269337105bf4


--

___
Python tracker 

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

[issue15927] csv.reader() does not support escaped newline when quoting=csv.QUOTE_NONE

[Sebastian Bank]

Sebastian Bank  added the comment:

To be complete, the docs of Dialect.escapechar should probably also say that it 
is used to escape itself.
However, note that csw.writer currently only does this with csv.QUOTE_NONE 
(breaking round-trip otherwise: #12178).

--

___
Python tracker 

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

[issue32346] Speed up slot lookup for class creation

[INADA Naoki]

INADA Naoki  added the comment:

As my understand, this patch creates cache for all classe,
not only for parent classes.
Caches may has much tuples, and they are GC tracked because
they contains function descriptors.  And they actually creates
reference cycles.

Am I correct?

If so, I want estimate of GC overhead and memory overhead of cache
for large project.  Is it really negligible?

--

___
Python tracker 

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

Re: Simple graphic library for beginners

[Paul Moore]

On 12 January 2018 at 09:12, Tim Golden  wrote:
> I think the shame here is that there is a learning opportunity on both
> sides. As Paul says: by and large, the huge amount of work which the Python
> Packaging team, especially the pip developers, have put in has paid off.
> It's now usually possible to say: "pip install XXX" and have it work out of
> the box for any recentish version of Python on any recentish version of a
> mainstream OS. Once people understand the basics of using that "interface",
> many things become simple.
>
> Unfortunately, where that *doesn't* work, it probably won't be because of
> low-hanging fruit: it'll be because of some strange interaction of different
> versions, odd leftover PATH setups, obscure Windows C Runtime redistribution
> issues, poor encoding interactions between Python and the Windows console,
> and so on.

Agreed. The other factor, and in my experience one of the most
frustrating to deal with, is when people *don't* start with "pip
install XXX", but instead find some complex process on the web, try
that, have it fail, and then we have to help them untangle whatever
mess that might have left for them. That's really annoying because we
can't really do anything about out of date information - and expecting
people to realise that things are moving fast enough that 6 month old
instructions are out of date isn't realistic either. (In fact, until
this thread I wasn't aware that pygame had published wheels, so I'd
have probably tried something unnecessarily complex myself - just
proves that even being intimately familiar with the packaging
ecosystem isn't enough!!!)

> All of these admit of solutions (if only by way of more informative error
> messages and useful FAQs) but they take time and patience to reproduce and
> work through. Many people -- and especially beginners -- don't really have
> the time or the inclination to follow through. They're not really interested
> in the mechanics of pip or the interaction of Python with the Windows
> installation subsystem. They just want to use numpy or pygame, or whatever.
>
> Where there *are* people who are willing to take the time to work things
> through, we [the Python community and especially the packaging/pip crew] can
> welcome them and try to identify weak spots in our own story. But of course
> we react poorly if someone wants merely to dismiss stuff. (Typical tweet:
> "Sigh; Python packaging is still broken!").
>
> I've actually been installing pygame quite a few times recently as part of a
> Coding Dojo I help to run once a term at a school in South London. And, even
> with the wonderful packaging work which the pygame guys have done to get
> wheels on PyPI, it's still sometimes a little painful. Of course, in that
> context, I'm just hustling to get people up-and-running and I'll do whatever
> it takes without stopping to take notes. So I sympathise when people say
> it's not easy for them. But not when they're dismissive about it.

Understood. I've recently been working with a complete beginner, and
it's quite surprising (and a real eye-opener) where the pain points
lie. Running python and pip (PATH issues) was a huge problem, but "pip
install numpy" was trivial. That's totally not what I'd expected...
Often the big issue for people like myself working on packaging is
being too close to the problem, and as a result focusing on the wrong
things. *Any* feedback from beginners is good for improving that
situation.

If you have any details on particular pain points your users have
experienced, feel free to pass them on to me and I'll see if I can
work them into something actionable. I understand what you mean
though, getting details of what's wrong isn't the priority when you
have a class to get running.

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

Re: Simple graphic library for beginners

[Paul Moore]

On 12 January 2018 at 06:47, Steven D'Aprano
 wrote:
> On Fri, 12 Jan 2018 12:45:04 +1300, Gregory Ewing wrote:
>
>> Seems to me it would help if pip were to announce which version of
>> Python it's installing things into. And instead of just saying "not
>> compatible with this version of Python", say "not compatible with Python
>> X.Y.Z". That would make these kinds of problems much easier to diagnose.
>
> This.

That does indeed sound like a reasonable suggestion. I don't know
immediately where in the code we'd put something like that (a banner
that says "Installing packages into Python at " wouldn't
be too hard, it could probably be added near the top of
pip._internal.commands.InstallCommand.run(), but the compatibility
stuff is a lot trickier because of how pip's finder works) but I'm
sure PRs would be acceptable.

> If pip is joined at the hip to a specific version of Python, I think that
> we ought to be able to specify the version number like we can with Python.
>
> Something like:
>
> pip ...  # use whichever version of pip comes first on the PATH
> pip3.6 ...  # use the pip installed with Python 3.6
> pip2.7 ...  # use the pip installed with Python 2.7

Well, that's sort of how it's intended to work, but in practice it
doesn't seem to be as straightforward as it ought to be. I can't
really say why, as it's a Unix-only thing and I don't really
understand the reasons, but it's why I'm a fan of the "python -m pip"
approach. There's discussion on the pip tracker if you're interested
enough to go searching - I know it's something that's been debated,
but I don't recall the context.

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

[issue18369] X509 cert class for ssl module

[Christian Heimes]

Christian Heimes  added the comment:

More examples:

>>> import ssl, socket, pprint
>>> ctx = ssl.create_default_context()
>>> sock = ctx.wrap_socket(socket.socket(), server_hostname="www.python.org")
>>> sock.connect(("www.python.org", 443))
>>> pprint.pprint(sock._sslobj._sslobj.verified_chain())
(<_ssl.Certificate '/businessCategory=Private 
Organization/jurisdictionC=US/jurisdictionST=Delaware/serialNumber=3359300/street=16
 Allen Rd/postalCode=03894-4801/C=US/ST=New Hampshire/L=Wolfeboro/O=Python 
Software Foundation/CN=www.python.org'>,
 <_ssl.Certificate '/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 
Extended Validation Server CA'>,
 <_ssl.Certificate '/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High 
Assurance EV Root CA'>)

>>> eecert = sock._sslobj._sslobj.verified_chain()[0]
>>> eecert.check_hostname('www.python.org')
'www.python.org'
>>> eecert.check_hostname('www.python.com')
False

>>> cert = ssl.Certificate.from_file('wildcards-combined.rsa.pem')
>>> pprint.pprint(cert.get_info())
{'OCSP': ('http://testca.pythontest.net/ca/ocsp/pysubca',),
 'caIssuers': ('http://testca.pythontest.net/ca/pysubca.cer',),
 'crlDistributionPoints': ('http://testca.pythontest.net/ca/pysubca.crl',),
 'issuer': ((('countryName', 'XZ'),),
(('stateOrProvinceName', 'Holy Grail'),),
(('organizationName', 'Castle Anthrax'),),
(('organizationalUnitName', 'Python Software Foundation'),),
(('commonName', 'Python Tests Intermediate CA'),)),
 'notAfter': 'Jan  1 12:00:00 2027 GMT',
 'notBefore': 'Jan  1 12:00:00 2017 GMT',
 'serialNumber': '0A',
 'subject': ((('countryName', 'XZ'),),
 (('stateOrProvinceName', 'Holy Grail'),),
 (('organizationName', 'Castle Anthrax'),),
 (('organizationalUnitName', 'Python Software Foundation'),),
 (('commonName', 'Wildcards in SAN'),)),
 'subjectAltName': (('DNS', '*.wildcard.pythontest.net'),
('DNS', 'www*.wildcard-www.pythontest.net'),
('DNS', 'x*.wildcard-x.pythontest.net')),
 'version': 3}
>>> cert.check_hostname('www.wildcard.pythontest.net')
'*.wildcard.pythontest.net'

--

___
Python tracker 

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

[issue27643] test_ctypes fails on AIX with xlc

[Michael Felt]

Michael Felt  added the comment:

@panter - your patch seems to be working well. Thanks.

PR 5164 submitted for review

--

___
Python tracker 

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

[issue27643] test_ctypes fails on AIX with xlc

[Michael Felt]

Change by Michael Felt :


--
pull_requests: +5020

___
Python tracker 

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

Re: Simple graphic library for beginners

[Paul Moore]

On 12 January 2018 at 06:45, Steven D'Aprano
 wrote:
>> The recommendation was already given to use "python3 -m pip". That gets
>> around those problems.
>
> If you google for installation instructions, they're nearly always given
> in terms of "use pip", not "use python3.4 -m pip".
>
> My point isn't that there is *no* solution to this problem, but that its
> not necessarily an *obvious* solution.

We've discussed this a number of times on the pip mailing lists and
changing recommendations like this is a slow and difficult process.
We're only just managing to get people to change websites from
recommending easy_install...

The question of "pip" vs "python -m pip" is a hard one. On Windows,
"py -m pip" is better for a lot of reasons, but the Unix users
involved in the debates were pretty reluctant to standardise on
"python -m pip" rather than the familiar "pip" (or "pip3"? I'm not
sure I completely follow what is natural for Unix users). Personally,
I still think a lot of confusion would be addressed if we settled on
"python -m pip" (with the established understanding that "python"
stands for whichever of "python", "python2", "python3", "py",
"/full/path/to/python", ... you're using to access Python) - but I
don't know how we make that the "obvious" approach.

For all of Bart's rhetoric, it *is* hard to find a good way to present
a consistent message when people go to Google/Stack Overflow first,
and only check the official docs as a last resort.

>>> How do I deal with permissions errors? [semi-rhetorical question -- I
>>> know *an* answer, but I don't know if it is the *right* answer]
>>
>> That's a fair point, but a perms error is reported properly by pip.
>
> Is it? Last time I tried, I just got an uninformative error that the
> package installation failed. Admittedly that was probably a year or two
> ago, so maybe the error message has been improved.

Installs from wheels are not bad, as pip is in control of the whole
process. Installs from source are dreadful, because it's
setuptools/distutils that give the errors and pip can't do anything
more than report the tracebacks produced (we tried trimming junk and
summarising, and got lots of complaints about hiding the causes of
problems).

But pip's error reporting isn't wonderful. We do tend to spew out
tracebacks rather than user-friendly messages. It's usually easy
enough to work out what the common tracebacks mean, but they are still
an intimidating wall of text to a non-expert. The usual "contributions
accepted" applies here, as pip developer time is extremely limited,
but it's not going to be an easy task for anyone.

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

[issue18369] X509 cert class for ssl module

[Christian Heimes]

Christian Heimes  added the comment:

API example:

>>> import ssl

>>> chain = ssl.Certificate.chain_from_file("Lib/test/ssl_cert.pem")
>>> cas = ssl.Certificate.bundle_from_file("Lib/test/pycacert.pem")
>>> pkey = ssl.PrivateKey.from_file("Lib/test/ssl_key.passwd.pem")
Traceback (most recent call last):
  File "", line 1, in 
ssl.SSLError: [PEM: BAD_PASSWORD_READ] bad password read (_ssl.c:58)
>>> pkey = ssl.PrivateKey.from_file("Lib/test/ssl_key.passwd.pem", 
>>> password="somepass")

>>> chain
(<_ssl.Certificate '/C=XY/L=Castle Anthrax/O=Python Software 
Foundation/CN=localhost'>,)
>>> cas
[<_ssl.Certificate '/C=XY/O=Python Software Foundation CA/CN=our-ca-server'>]

>>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
>>> ctx.load_cert_chain(chain, pkey)
>>> ctx.load_verify_locations(cadata=cas)

--

___
Python tracker 

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

[issue16487] Allow ssl certificates to be specified from memory rather than files.

[Christian Heimes]

Christian Heimes  added the comment:

Senthil,

I'm not a fan of PR 2449 because it provides yet another way to load 
certificates and keys from memory. It's a clever idea to use MemoryBIO here. 
But the approach is *not* compatible with PEP 543. The PEP requires an API that 
can turn a memory blob into a series of certificate objects. PR 2449 doesn't 
enable memory -> certificate. The new API is OpenSSL specific and restricted to 
PKCS#8 key in PEM/DER encoding. PEP 543 is extensible for PKCS#11, engine and 
HSM support. PR 2449 is not.

There are other issues with PR 2449. For example it's missing several GIL 
releases calls. The password callback doesn't look correct in some places.

https://github.com/python/cpython/pull/5162 provides a PEP 543-compatible 
implementation (plus additions from pending PR):

>>> import ssl

>>> chain = ssl.Certificate.chain_from_file("Lib/test/ssl_cert.pem")
>>> cas = ssl.Certificate.bundle_from_file("Lib/test/pycacert.pem")
>>> pkey = ssl.PrivateKey.from_file("Lib/test/ssl_key.passwd.pem")
Traceback (most recent call last):
  File "", line 1, in 
ssl.SSLError: [PEM: BAD_PASSWORD_READ] bad password read (_ssl.c:58)
>>> pkey = ssl.PrivateKey.from_file("Lib/test/ssl_key.passwd.pem", 
>>> password="somepass")

>>> chain
(<_ssl.Certificate '/C=XY/L=Castle Anthrax/O=Python Software 
Foundation/CN=localhost'>,)
>>> cas
[<_ssl.Certificate '/C=XY/O=Python Software Foundation CA/CN=our-ca-server'>]

>>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
>>> ctx.load_cert_chain(chain, pkey)
>>> ctx.load_verify_locations(cadata=cas)

# get_ca_certs() doesn't return ssl.Certificates yet
>>> ctx.get_ca_certs()
[{'subject': ((('countryName', 'XY'),), (('organizationName', 'Python Software 
Foundation CA'),), (('commonName', 'our-ca-server'),)), 'issuer': 
((('countryName', 'XY'),), (('organizationName', 'Python Software Foundation 
CA'),), (('commonName', 'our-ca-server'),)), 'version': 3, 'serialNumber': 
'B09264B1F2DA21D0', 'notBefore': 'Jan  4 19:47:07 2013 GMT', 'notAfter': 'Jan  
2 19:47:07 2023 GMT'}]

--

___
Python tracker 

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

[issue32473] Readibility of ABCMeta._dump_registry()

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +5019

___
Python tracker 

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

[issue32473] Readibility of ABCMeta._dump_registry()

[INADA Naoki]

INADA Naoki  added the comment:


New changeset ae12f5d4c98f2095c2aadd58981453e955044697 by INADA Naoki 
(yahya-abou-imran) in branch 'master':
bpo-32473: Improve ABCMeta._dump_registry() readability (GH-5091)
https://github.com/python/cpython/commit/ae12f5d4c98f2095c2aadd58981453e955044697


--
nosy: +inada.naoki

___
Python tracker 

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

Re: Simple graphic library for beginners

[Tim Golden]

On 12/01/2018 08:47, Paul Moore wrote:

On 12 January 2018 at 01:21, bartc  wrote:

On 11/01/2018 23:23, Chris Angelico wrote:


On Fri, Jan 12, 2018 at 10:11 AM, bartc  wrote:




I'm almost ready to plonk you, but I think there is still SOME value
in your posts. But please, stop denigrating what you don't understand.



And please try to see things from the pointer of view of a beginner or
outsider, where anything to do with Python seems to have a bewildering and
conflicting array of solutions.


The beginners I've worked with downloaded Python 3.6 and did "pip
install numpy", successfully and without help from me. Sure, some
beginners have issues, but they are usually willing to be helped. To
be as aggressively resistant to the simplest suggestions the way
you're being isn't the behaviour of a beginner in my experience.


I think the shame here is that there is a learning opportunity on both 
sides. As Paul says: by and large, the huge amount of work which the 
Python Packaging team, especially the pip developers, have put in has 
paid off. It's now usually possible to say: "pip install XXX" and have 
it work out of the box for any recentish version of Python on any 
recentish version of a mainstream OS. Once people understand the basics 
of using that "interface", many things become simple.


Unfortunately, where that *doesn't* work, it probably won't be because 
of low-hanging fruit: it'll be because of some strange interaction of 
different versions, odd leftover PATH setups, obscure Windows C Runtime 
redistribution issues, poor encoding interactions between Python and the 
Windows console, and so on.


All of these admit of solutions (if only by way of more informative 
error messages and useful FAQs) but they take time and patience to 
reproduce and work through. Many people -- and especially beginners -- 
don't really have the time or the inclination to follow through. They're 
not really interested in the mechanics of pip or the interaction of 
Python with the Windows installation subsystem. They just want to use 
numpy or pygame, or whatever.


Where there *are* people who are willing to take the time to work things 
through, we [the Python community and especially the packaging/pip crew] 
can welcome them and try to identify weak spots in our own story. But of 
course we react poorly if someone wants merely to dismiss stuff. 
(Typical tweet: "Sigh; Python packaging is still broken!").


I've actually been installing pygame quite a few times recently as part 
of a Coding Dojo I help to run once a term at a school in South London. 
And, even with the wonderful packaging work which the pygame guys have 
done to get wheels on PyPI, it's still sometimes a little painful. Of 
course, in that context, I'm just hustling to get people up-and-running 
and I'll do whatever it takes without stopping to take notes. So I 
sympathise when people say it's not easy for them. But not when they're 
dismissive about it.


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

[issue18369] X509 cert class for ssl module

[Christian Heimes]

Change by Christian Heimes :


--
pull_requests: +5018

___
Python tracker 

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

Re: Simple graphic library for beginners

[Paul Moore]

On 12 January 2018 at 01:21, bartc  wrote:
> On 11/01/2018 23:23, Chris Angelico wrote:
>>
>> On Fri, Jan 12, 2018 at 10:11 AM, bartc  wrote:
>
>
>> I'm almost ready to plonk you, but I think there is still SOME value
>> in your posts. But please, stop denigrating what you don't understand.
>
>
> And please try to see things from the pointer of view of a beginner or
> outsider, where anything to do with Python seems to have a bewildering and
> conflicting array of solutions.

The beginners I've worked with downloaded Python 3.6 and did "pip
install numpy", successfully and without help from me. Sure, some
beginners have issues, but they are usually willing to be helped. To
be as aggressively resistant to the simplest suggestions the way
you're being isn't the behaviour of a beginner in my experience.

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

Re: Simple graphic library for beginners

[Monte Milanuk]

On 2018-01-11 12:37, Oivvio Polite wrote:

On ons, jan 10, 2018 at 01:40:28 +0100, Jan Erik Moström wrote:

I'm looking for a really easy to use graphic library. The target users are
teachers who have never programmed before and is taking a first (and
possible last) programming course.



I do a two day workshop for design and illustration students once a year
and use Processing (https://processing.org) for it. It's a programming
tool primarly for visual artists. The original version uses a subset of
Java but there is also a python mode (https://py.processing.org). I've
found it quite appropriate for an educational setting.




I was going to suggest p5.js... the tutorials on YouTube under 'The 
Coding Train' are pretty helpful.


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

Re: Simple graphic library for beginners

[Chris Angelico]

On Fri, Jan 12, 2018 at 5:45 PM, Steven D'Aprano
 wrote:
> On Fri, 12 Jan 2018 12:14:03 +1100, Chris Angelico wrote:
>>> How do I deal with permissions errors? [semi-rhetorical question -- I
>>> know *an* answer, but I don't know if it is the *right* answer]
>>
>> That's a fair point, but a perms error is reported properly by pip.
>
> Is it? Last time I tried, I just got an uninformative error that the
> package installation failed. Admittedly that was probably a year or two
> ago, so maybe the error message has been improved.

Hmm. Last time I tried, it was pretty informative, but that was on
Linux. I actually don't know about Windows, and whether there are
weird situations that would result in obscure messages. Would have to
get someone to try it.

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

Re: Simple graphic library for beginners

[Christian Gollwitzer]

Am 11.01.18 um 06:16 schrieb Michael Torrie:

On 01/10/2018 01:13 PM, bartc wrote:

I couldn't see anything obviously simple there. A lot seems to do with
interaction which is always much more complicated than just drawing stuff.


Yes the link didn't have the simple examples I hoped for.  How's this:
-
import pygame
import time

pygame.init()
screen = pygame.display.set_mode((1024, 768) )
red = (255,0,0)
green = (0,255,0)

screen.fill( (255,255,255) )
pygame.draw.lines(screen, red, False, ((0,0),(100,100)))
pygame.draw.lines(screen, green, False, ((0,100),(100,0)))
pygame.display.update()

time.sleep(5)
pygame.quit()
--


This looks very reasonable. If one wants buttons, however, I still 
recommend to use Tkinter. The same program looks not much more complex:


--
import tkinter as Tk
from tkinter import ttk
# Boilerplate: set up a resizeable canvas in a window
root   = Tk.Tk()
canvas = Tk.Canvas(root)
canvas.pack(expand=True, fill='both')


canvas.create_line(0, 0, 100, 100, fill='red')
canvas.create_line(0, 100, 100, 0, fill='green')

# add a button to close the program
button = ttk.Button(root, text='Leave', command=exit)
button.pack()

# run the program
Tk.mainloop()
---

The boilerplate looks a bit less intuitive - instead of pygame.init() 
you have to set up a canvas in a window - but the actual drawing code 
looks quite similar. And it is trivial to add a button or other widgets, 
as shown above.


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