date:20181011


Change by Alexander Böhn :


--
versions: +Python 3.8

___
Python tracker 

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

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing


Change by Alexander Böhn :


--
components: +Library (Lib) -Extension Modules

___
Python tracker 

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

[issue34748] Incorrect HTML link in functools.partial

2018-10-11 Thread Roundup Robot



Change by Roundup Robot :


--
keywords: +patch
pull_requests: +9188
stage: needs patch -> patch review

___
Python tracker 

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

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing


Change by Alexander Böhn :


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

___
Python tracker 

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

[issue34963] String representation for types created with typing.NewType(…) are opaque and unappealing


New submission from Alexander Böhn :

When creating a new type with `typing.NewType(…)` the result is a function 
defined on-the-fly with no reasonable `__repr__` definition – the string 
representation of the type looks something like e.g. “.new_type at 0x108ae6950>” which isn’t very useful or 
aesthetically appealing.

--
components: Extension Modules
messages: 327558
nosy: fish2000
priority: normal
severity: normal
status: open
title: String representation for types created with typing.NewType(…) are 
opaque and unappealing
type: behavior
versions: Python 3.7

___
Python tracker 

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

[issue34893] Add 2to3 fixer to change send and recv methods of socket object.

2018-10-11 Thread Pranav Devarakonda



Pranav Devarakonda  added the comment:

I have added a final condition that converts the arguments passed to bytes only 
if the type of object is socket and the method is send() in the generated code. 
All the other conversions still function as expected.

--
Added file: https://bugs.python.org/file47864/fix_socket_send_recv_reupdated.py

___
Python tracker 

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

[issue34956] _tkinter built on macOS 10.14 does not link to Tcl and Tk in /Library/Frameworks

2018-10-11 Thread Kevin Walzer



Kevin Walzer  added the comment:

Thank you, this helped.

--

___
Python tracker 

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

[issue27741] datetime.datetime.strptime functionality description incorrect



Change by Ned Deily :


--
nosy: +belopolsky

___
Python tracker 

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

[issue27741] datetime.datetime.strptime functionality description incorrect

2018-10-11 Thread Gus Goulart



Change by Gus Goulart :


--
nosy: +taleinat

___
Python tracker 

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

[issue27741] datetime.datetime.strptime functionality description incorrect

2018-10-11 Thread Gus Goulart



Gus Goulart  added the comment:

It is true that time.srtptime() does not return microseconds, but as the 
documentation suggests, it will return the microseconds after you wrap it up 
with datetime().
I have attached a walkthrough of how I see that section of the docs. Please let 
me know if you have anything else in mind. Thanks!

--
nosy: +gus
Added file: https://bugs.python.org/file47863/datetime_docs.PNG

___
Python tracker 

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

Single DB connection during class's lifetime. Metaclass, singleton and new() examples and references.

2018-10-11 Thread Ryan Johnson

I am working on using mysql.connector in a class and have found an example of 
how to create a single connection that spans the lifetime of all instances of 
the class:

https://softwareengineering.stackexchange.com/a/358061/317228 

however, I do not understand a few things about the class, including

1. Why it is subclassed as an object: `class Postgres(object):` ? I thought 
classes were necessarily objects.
2. Why is this portion of code directly addressing the class, instead of using 
the `cls` reference variable?
connection = Postgres._instance.connection = psycopg2.connect(**db_config)
cursor = Postgres._instance.cursor = connection.cursor()
3. And is it me or does anyone else think {anydb}.connector’s usage is messy 
and inelegant? Ex:
print('connecting to PostgreSQL database...')
connection = Postgres._instance.connection = psycopg2.connect(**db_config)
cursor = Postgres._instance.cursor = connection.cursor()
cursor.execute('SELECT VERSION()')
db_version = cursor.fetchone()
Why can’t we associate the focus of the connection with the connection 
itself, instead of creating a separate cursor object?

Also, within the code example, and in Python in general, why does there needs 
to be a __new__ constructor when there’s an __init__ constructor? I’ve read 
about the usage of singletons. It seems you could create singletons within  
__init__ or __new__ . Any enlightenment would be really helpful. I am very 
sleep-deprived, so I’m sorry if this seems like a dumb question.

I have read the official docs. Have also been reading “Python 3: Patterns, 
Recipes, and Idioms”. The first was mildly helpful but I still don’t see the 
benefit of a __new__ constructor.
Why is there dislike for Metaclasses?

Thanks, and I’ll have better incisive questions in the future.

Sent from Mail for Windows 10

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

Re: Observations on the List - "Be More Kind"

On Fri, Oct 12, 2018 at 5:07 AM Ian Kelly  wrote:
>
> On Thu, Oct 11, 2018 at 9:28 AM Dan Purgert  wrote:
> >
> > Larry Martell wrote:
> > > On Fri, Oct 5, 2018 at 6:54 AM Bruce Coram  wrote:
> > > [...]
> > > We don't like you. We don't want you here. We never will. Save us all
> > > the trouble and go away.
> >
> > That's the best code of conduct I've ever read ... 10/10, would read
> > again.
>
> For 4chan, maybe.

He said "would read again". I absolutely agree. This is a CoC that is
worth reading again.

Worth adopting for python-list? Ehh, not so much. But it's definitely
worth reading again. :)

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

[issue34939] Possibly spurious SyntaxError: annotated name can't be global

2018-10-11 Thread Ivan Levkivskyi



Ivan Levkivskyi  added the comment:

I think we can just go ahead and allow this. If there is a volunteer, please go 
ahead, otherwise I will try to find time for this myself.

--

___
Python tracker 

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

[issue34962] make doctest does not pass :/


Change by Stéphane Wirtel :


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

___
Python tracker 

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

[issue34962] make doctest does not pass :/


New submission from Stéphane Wirtel :

make -C Doc/ doctest does not pass the tests.

--
messages: 327553
nosy: matrixise
priority: normal
severity: normal
status: open
title: make doctest does not pass :/
versions: Python 3.8

___
Python tracker 

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

[issue34960] macOS builds expose stack_size option in LINKEDFOORSHARED and pyconfig



Simon Wells  added the comment:

oh the rabbit hole...

as i have other builds of python3.7 on my system i wanted to ensure it used the 
correct python and python-config (python 3.7 was built and installed into 
$HOME/Projects/python/inst/) as such its a rather convoluted configure command 
for libxml2

LDFLAGS="-L$HOME/Projects/python/inst/lib" 
PATH=/Users/simon/Projects/python/inst/bin/:$PATH ./configure 
--prefix=/Users/simon/Projects/python/inst/ 
--with-python=/Users/simon/Projects/python/inst/bin/python3 
--with-python-install-dir=/Users/simon/Projects/python/inst/lib/python3.7/site-packages

the LDFLAGS envvar was required as python-config --ldflags also does not 
provide -L for the python libary

$make
ld: library not found for -lpython3.7m

in config.log for libxml2 (PYTHON_LIBS which is the output of 
$HOME/Projects/python/python3-config --ldflags)
PYTHON_LIBS='-lpython3.7m -ldl -framework CoreFoundation 
-Wl,-stack_size,100 -framework CoreFoundation'


after LDFLAGS="..." is added

$make
...
  CCLD libxml2mod.la
ld: -stack_size option can only be used when linking a main executable
clang: error: linker command failed with exit code 1 (use -v to see invocation)

if you want more log lines please let me know but those should be the only 
relevant ones

--

___
Python tracker 

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

[issue34960] macOS builds expose stack_size option in LINKEDFOORSHARED and pyconfig



Ned Deily  added the comment:

OK, now I finally get it, thanks, my fault.  Yes, we probably shouldn't be 
passing stack_size through to applications trying to embed Python in 
LINkFORSHARED and pyconfig.  That's an area that we don't test very well nor 
have tests for, AFAIK.  Would it possible for you to provide a simple example 
of building libxml2 that would allow us to more easily test this?

https://docs.python.org/3/extending/embedding.html#compiling-and-linking-under-unix-like-systems

--
title: python-config bad ldflags on macOS -> macOS builds expose stack_size 
option in LINKEDFOORSHARED and pyconfig
versions: +Python 3.8

___
Python tracker 

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

[issue34960] python-config bad ldflags on macOS



Simon Wells  added the comment:

ah ok, sorry i wasn't clear at first, the issue isn't when building python its 
when building a library which depends on python in this case libxml2, which 
when given the --enable-python stuff uses 
"PYTHON_LIBS=`python$PYTHON_VERSION-config --ldflags`" and therefore is being 
given the -Wl,stack_size linker option which is not valid for non main 
executables according to the error produced from clang

--

___
Python tracker 

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

[issue34960] python-config bad ldflags on macOS



Ned Deily  added the comment:

Oh, you didn't mention --enable-shared!  But still it's not clear to me what 
problem your last results shows.  The value of python3-config --ldflags looks 
fine (ignore the repeated -framework CoreFoundation).  Are you still getting 
the "ld: -stack_size option can ...' message when you built the second time?  
An installed --enable-shared build for me works just fine when using a 
non-standard prefix, i.e. a location where there is not already a Python3 
installed.  So I still can't reproduce a problem.

By the way, I always recommend to avoid using the --enable-shared option for 
macOS builds; I know there are cases in the past where there *has* been build 
issues when building shared and there is already a Python installed at that 
prefix.  If possible, stick either a "plain Unix" build (no --enable-shared, no 
--enable-framework) or a framework build.  You're less likely to run into at 
first glance head-scratching building and linking issues.

--

___
Python tracker 

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

[issue34960] python-config bad ldflags on macOS



Simon Wells  added the comment:

with a fresh 3.7.0 download

./configure --prefix=... --enable-shared
make -j5
make install

path/to/python3-config --ldflags
-lpython3.7m -ldl -framework CoreFoundation -Wl,-stack_size,100 -framework 
CoreFoundation

--

___
Python tracker 

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

[issue34961] Global scoping when shadowing local names in class definitions

2018-10-11 Thread multun



New submission from multun :

Hello,

>>> a="global"
>>> def func(a):
... class wtf():
... a=a
... return wtf
... 
>>> func("local").a
'global'
>>> def func2(a):
... class wtf():
... b=a
... return wtf
... 
>>> func2("local").b
'local'


Is this behavior legit ?

Best regards,

--
Victor "multun" Collod

--
components: Interpreter Core
files: weird_class_scope.py
messages: 327547
nosy: multun
priority: normal
severity: normal
status: open
title: Global scoping when shadowing local names in class definitions
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47862/weird_class_scope.py

___
Python tracker 

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

[issue34960] python-config bad ldflags on macOS



Ned Deily  added the comment:

Sorry, I can't reproduce that behavior.  What's more, that LINKFORSHARED value 
does not appear to be correct.  Have you tried doing a build from a clean build 
dicectory while rerunning ./configure?  What does your ./configure look like 
and do have any relevant env variables set?

>>> sysconfig.get_config_var('LINKFORSHARED')
'-Wl,-stack_size,100  -framework CoreFoundation'

--

___
Python tracker 

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

[issue34960] python-config bad ldflags on macOS



New submission from Simon Wells :

if you didn't build python as a framework it adds 
sysconfig.get_config_vars('LINKFORSHARED') when you run 'python-config 
--ldflags' this resolves to

>>> sysconfig.get_config_var('LINKFORSHARED')
'-Wl,-stack_size,100  -framework CoreFoundation 
/usr/local/opt/python/Frameworks/Python.framework/Versions/3.7/Python'

the '-Wl,-stack_size' ldflag causes issues for clang with the error

"ld: -stack_size option can only be used when linking a main executable"

--
components: macOS
messages: 327545
nosy: ned.deily, ronaldoussoren, xzcvczx
priority: normal
severity: normal
status: open
title: python-config bad ldflags on macOS
type: behavior
versions: Python 3.6, Python 3.7

___
Python tracker 

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

Re: Observations on the List - "Be More Kind"

2018-10-11 Thread Ian Kelly

On Thu, Oct 11, 2018 at 9:28 AM Dan Purgert  wrote:
>
> Larry Martell wrote:
> > On Fri, Oct 5, 2018 at 6:54 AM Bruce Coram  wrote:
> > [...]
> > We don't like you. We don't want you here. We never will. Save us all
> > the trouble and go away.
>
> That's the best code of conduct I've ever read ... 10/10, would read
> again.

For 4chan, maybe.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: From Mathematica to Jypyter

2018-10-11 Thread eryk sun

On Thu, Oct 11, 2018 at 4:10 AM Thomas Jollans  wrote:
>
> On 2018-10-11 10:48, jfine2...@gmail.com wrote:
> > It is fun to find fault in the work of a new Nobel laureate. In this case, 
> > a typo.
>
> Not a Nobel laureate. It's not a Nobel prize.

More precisely it's the Nobel Memorial Prize in Economics, established
by the central bank of Sweden in 1968, not Alfred Nobel in 1895.
Recipients of this prize are counted among Nobel laureates, though
it's not without controversy.

https://en.wikipedia.org/wiki/List_of_Nobel_laureates
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ESR "Waning of Python" post

2018-10-11 Thread Neil Cerutti

On 2018-10-10, Paul Rubin  wrote:
> Neil Cerutti  writes:
>> As Stephen said, it's sort of silly not to be aware of those
>> issues going in.
>
> If you're saying ESR messed up by using Python in the first
> place for that program, that's not a great advert for Python
> either.

I meant Stefan, by the way. Sorry, Stefan.

I actually do kind of think that, but ESR is a much better
and more experienced programmer than me and a whole lot more
knowledgable about the resource usage his program requires. So take
that part of my opinion with a grain of salt, if you didn't
already have one. Somebody in his comments section was
incredulous that his software could possible bog down with such a
"small" code base.

It concerning to me that he glossed over his decision process
when abandoning the idea of offloading the part of the work
that's getting stuck in one core to a suitable engine. To me,
that has to be easier than rewriting from scratch in a new
language, but we don't have enough information to judge.

One issue I didn't address was his criticism of deploying Python
programs, thanks to library location issues. As I understand it,
Go's library system has it own huge bloc of complainants regaring
versioning hell, with a solution that's vaporware. Python's
library issues can be addressed with virtualenv or py2exe type
tools.

I also disliked how he lumped current problems with Python in
together with "ancient" history.

It was definitely a good enough article for a blog post but would
need rewriting for a journal or a magazine.

>>> the GIL (15/16th of his CPUs are unused..)
>> Channels are a big selling point of Go, no argument there.
>
> The unused CPUs are not about channels (Python has Queue which
> is similar).  They're about the GIL, which is an implementation
> artifact of CPython that's hard to eliminate without modifying
> CPython's C API.  ESR didn't say this explicitly but it came to
> mind when reading his post: It's weird that Python's designers
> were willing to mess up the user language in the 2-to-3
> transition but felt that the C API had to be kept sarcosanct.
> Huge opportunities were blown at multiple levels.

OK. I assumed he planned to parallelize computations in Go by
offloading to concurrent channels--I guess I don't understand why
he can't do that in Python.

>> You must carefully use a different set of functions and
>> operators to regard the bytes as unicode code-points. So Go
>> makes it easy to do things incorrectly
>
> That seems like a deficiency in Go's type system rather than in
> the UTF8 representation per se.  

I agree. Python could've used UTF8 as the internal representation
as well, but there's no need to go back into that jmxfauth horror
show.

>> On the other hand, I only used Go until it made me feel really
>> annoyed
>
> Yeah I haven't used Go a whole lot either, for similar and
> other reasons.  ESR's criticisms of Python are imho mostly
> valid but I don't think Go is the answer.  It's too low level,
> showing its roots in C. Haskell and Ocaml have their own
> deficiencies but I think they are closer to the right
> direction.  I.e. I'd like something with a serious type system
> and a more functional-programming flavor than either Go or
> Python currently have.

A big reason he chose Go in the article is that he regarded it as
more simple to translate Python->Go than those other options.
It's hard to believe that good Python code would make could Go
code, but at least its a starting point. I imagine that if I
stuck with Go long enough I'd develop a new coding style that
didn't inolve creating useful data types. I've used C++ and
Python so long I just don't think that way.

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

[issue2142] difflib.unified_diff(...) produces invalid patches

2018-10-11 Thread Mark Lawrence



Change by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

Re: ESR "Waning of Python" post

2018-10-11 Thread Tomasz Rola

On Thu, Oct 11, 2018 at 06:22:13PM +1100, Chris Angelico wrote:
[...]
> 
> There's a huge difference between deciding on using some different
> language for a project, and going on a massive ire-filled rant.

I agree, in fact this is the kind of posture that I myself
implemented in my actions. 

I have read the article, which was interesting, but am yet to read the
comments. I have a question. What is the size of data? I could not
spot it. If one had read it into one huge byte array, how many bytes
would it be? ESR says he makes a graph of it and there are ~350k
objects - i.e. nodes, I assume? How many edges (arcs, lines) for a
node, on average? on max?

I am curious, as always. Because it is nice of him to rant, but
technical/mathematical side of decision making is still a bit too
foggy for me and I cannot assess it.

-- 
Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.  **
** As the answer, master did "rm -rif" on the programmer's home**
** directory. And then the C programmer became enlightened...  **
** **
** Tomasz Rola  mailto:tomasz_r...@bigfoot.com **
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue34957] Segementation faults on ARM and ARM64

2018-10-11 Thread Zachary Ware



Zachary Ware  added the comment:

IIRC, the default in 3.6 is to use `--with-system-ffi` if available on all 
platforms but macOS, falling back to the bundled copy only if a system copy 
can't be found; 3.7 removes the bundled copy.  Also, the version bundled with 
3.6 is v3.2.1.

Note though that this is all from memory, I haven't actually gone to look at 
the code again :)

--

___
Python tracker 

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

[issue34957] Segementation faults on ARM and ARM64



STINNER Victor  added the comment:

> Upgrade to 3.7 fixed the main problem for me, or at least on the 
> hardware/arch I use.

For Python, we should try to identify the required backport, or upgrade libffi 
in Python 3.6. But I'm scared by Modules/_ctypes/libffi/ since it's unclear to 
me if we patched it or not...

IHMO the best option for FreeBSD would be to change how FreeBSD builds Python 
3.6 to use --with-system-ffi (use recent libffi rather than Python old copy).

--
nosy: +zach.ware

___
Python tracker 

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

[issue34811] test_gdb fails with latest gdb



STINNER Victor  added the comment:

Update: I reproduced the bug but then I was unable to go futher, I was blocked 
by gdb which decided to crash in Fedora rawhide (gdb 8.2.50.20181006-4.fc30) :-/

--

___
Python tracker 

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

[issue34957] Segementation faults on ARM and ARM64



Stefan Rink  added the comment:

Upgrade to 3.7 fixed the main problem for me, or at least on the hardware/arch 
I use.

-- On ARM32 it still failed but I don't have debugging symbols there so not so 
easy to troubleshoot further --

--
resolution:  -> works for me

___
Python tracker 

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

[issue34954] Getting an email's subject is error-prone

2018-10-11 Thread Alex Corcoles


Alex Corcoles  added the comment:

Duh, I'm an idiot, I only tested policy.HTTP and *NOT* supplying a policy 
(which I believed was equivalent to using policy.default).

policy.default and policy.SMTP do indeed produce a newline-less subject indeed.

I only tested policy.HTTP because the docs talk about unlimited line-length, 
but that's a problem of the docs, but rather, a problem of my idiocy.

Given this, I agree with everything you said. Personally I'd prefer if 
policy.default was the default, but I guess that won't change due to backwards 
compatibility reasons and I guess it'd be excessive to create a new set of 
function calls and deprecate the old, so I'm happy if this remains closed.

Apologies for my stupidity,

Álex

--

___
Python tracker 

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

[issue34576] [EASY doc] http.server, SimpleHTTPServer: warn users on security

2018-10-11 Thread Senthil Kumaran



Senthil Kumaran  added the comment:

@Victor - Surprising. Thanks for noticing this. I will fix it shortly.

--

___
Python tracker 

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

[issue34954] Getting an email's subject is error-prone

2018-10-11 Thread R. David Murray



R. David Murray  added the comment:

I'm guessing you got confused by the fact that the HTTP policy doesn't *add* 
new lines when *serializing*.  If you can point to the part of the docs you 
read that produced that confusion, maybe we can improve it.

--

___
Python tracker 

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

[issue34954] Getting an email's subject is error-prone

2018-10-11 Thread R. David Murray



R. David Murray  added the comment:

Can you demonstrate that policy.default and policy.SMTP produce a subject with 
newlines?  If they do, that is a serious bug.

Please don't reopen the issue.  I'll reopen it if you convince me there is a 
bug :)

The statement you suggest we add is not appropriate[*], since the python3 email 
library *is* a high level library now.  If it isn't handling something for you 
when you use policy.default or policy.SMTP, then that is a bug.  (Well, it's 
MIME Multipart handling still leaves something to be desired...you still have 
to know more than is optimal about multiparts, but the hooks are there for 
someone to improve that aspect further.)

[*] The part about the protocol is certainly true, though :)

--
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: Observations on the List - "Be More Kind"

2018-10-11 Thread Dan Purgert

Larry Martell wrote:
> On Fri, Oct 5, 2018 at 6:54 AM Bruce Coram  wrote:
> [...]
> We don't like you. We don't want you here. We never will. Save us all
> the trouble and go away.

That's the best code of conduct I've ever read ... 10/10, would read
again.

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281
-- 
https://mail.python.org/mailman/listinfo/python-list

AW: how to replace line on particular line in file[no need to write it back whole file again]

2018-10-11 Thread Lutz Horn

Try something like this:

```
import sys

def replace(lineno, replacement):
for i, line in enumerate(sys.stdin.readlines()):
if i == lineno:
line = replacement
print(line.strip())

replace(2, "REPLACEMENT")
```


Von: Python-list  im 
Auftrag von Iranna Mathapati 
Gesendet: Donnerstag, 11. Oktober 2018 11:44
An: python list
Betreff: how to replace line on particular line in file[no need to write it 
back whole file again]

Hi Team,

How to replace particular line text with  new text on a file
i have below code but its writing whole code.

def replace_line(file_name, line_num, text):
lines = open(file_name, 'r').readlines()
lines[line_num] = text
out = open(file_name, 'w')
out.writelines(lines)  < *writing back whole file instead of
particular line*
out.close()
replace_line('stats.txt', 0, 'good')


Thanks,
Iranna M
--
https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue34095] [2.7] test_idle fails with: /usr/bin/xvfb-run: line 181: 3617 Segmentation fault

2018-10-11 Thread Terry J. Reedy



Terry J. Reedy  added the comment:

Additional notes:

I am puzzled that test_idle output starts with test_io, as that is 
alphabetically in the middle of the files in idle_test/.

There are 2 independent 'test_io' modules: test/test_io, which tests the io 
module, and idlelib/test_idle/test_io, which tests idlelib.PyShell.PseudoFile 
and subclasses (which are all derived from io.TextIOBase).  Only the latter is 
an issue here.  The former is an irrelevant distraction and should not have 
been included with test_idle in msg321737.

Since log.all ends with "test_writelines 
(idlelib.idle_test.test_io.PseudeOutputFilesTest) ... /usr/bin/xvfb-run: line 
181: ...", I initially thought that test_writelines, in particular, stimulated 
the failure.  But in the msg321737 output, test_writelines ran 'OK'.

The fact that xvfv ... test_idle runs by itself but not when alphabetically 
preceding tests are run says that some preceding test alters something.   The 
failure of test_audioop seems an unlikely cause.  I suspect test__all__, by 
importing _tkinter either directly or via Tkinter or some IDLE module.  This 
could be tested with xvfb ... test___all__ test_idle.

Since the tests are mostly run alphabetically and the tkinter tests, test_tcl, 
test_tk, test_ttk_guionly, and test_ttk_textonly alphabetically follow 
test_idle, they should not be the cause of the crash during test_idle.  On the 
other hand, if the test above crashes, and so does 
xvbf ... -ugui test___all__ test_tcl test_tk test_ttk_guionly test_ttk_textonly
then test_idle would be eliminated as the direct culprit.

--

___
Python tracker 

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

[issue34957] Segementation faults on ARM and ARM64



Stefan Rink  added the comment:

On ARM32 it still crashed but on the ARM64 upgrade to 3.7 helped!
Need to do some more testing but it looks like it's working now.

# python3.7
Python 3.7.0 (default, Sep 29 2018, 05:58:20) 
[Clang 6.0.1 (tags/RELEASE_601/final 335540)] on freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>> from dask.distributed import Client
>>> client = Client()
>>> client.cluster
LocalCluster('tcp://127.0.0.1:22415', workers=4, ncores=4)

--

___
Python tracker 

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

[issue34959] Are the tests optional on travis?


Change by Stéphane Wirtel :


--
resolution:  -> rejected

___
Python tracker 

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

[issue34959] Are the tests optional on travis?


Stéphane Wirtel  added the comment:

this issue is useless :/

--
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: how to replace line on particular line in file[no need to write it back whole file again]

2018-10-11 Thread Iranna Mathapati

Thanks Dennis Lee and Thomas

On Thu, Oct 11, 2018 at 6:32 PM Dennis Lee Bieber 
wrote:

> On Thu, 11 Oct 2018 15:14:49 +0530, Iranna Mathapati
>  declaimed the following:
>
> >Hi Team,
> >
> >How to replace particular line text with  new text on a file
> >i have below code but its writing whole code.
> >
> 
>
> For C-style streams (which seem to have taken over every operating
> system) in which "lines" are determined by specific characters in the
> stream, you can only "replace" a line IF THE REPLACEMENT IS THE EXACT SAME
> SIZE! If there is any difference in length of the input and output lines,
> you have to read/write everything from the line to the end of the file.
>
> I emphasize "C-style streams" as there were operating systems that
> did
> support other file organizations natively. Xerox CP-V offered
> "consecutive", "keyed", and "random" file organizations.
>
> "Consecutive" being the closest to streams -- pure sequentially
> written
> data.
>
> "Keyed" files used a multi-level ISAM structure -- which is what
> was
> used by the text editor and by the FORTRAN direct-access mode (line/record
> numbers were used as the ISAM key). In these, replacing a line meant
> writing a new line  and updating the ISAM headers to point to
> the new line. Periodically one would have to pack the file to reclaim
> unused/freed space.
>
> "Random" files were an organization in which the OS did /nothing/.
> These files were created as a predetermined maximum size, and were
> allocated as a contiguous section of disk space -- the OS didn't even
> bother tracking blocks. An application basically was given two pieces of
> information: the starting address on disk, and the total length of the
> allocation. ALL data management had to be done by the application.
>
> Past that, there is the concept of a fixed-length record. ALL
> records
> (lines) in the file having the same predefined maximum length. Internally,
> each record would either have a length datum at the beginning, or use some
> special character to indicate where the end of the record's data really is
> -- but all I/O was performed on the full . Even
> TRSDOS/LS-DOS (TRS-80 Model III/4) supported fixed-length I/O in the OS,
> though the maximum record length was one disk sector (256 bytes; shorter
> records definitions were permitted and the system /did/ pack them into disk
> space rather than wasting the tail of the sector). Fixed length schemes
> typically permit direct access
>
> x = read(rec=123)
>
> write(y, rec=123)
>
>
>
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.new

2018-10-11 Thread Orivej Desh



Change by Orivej Desh :


--
nosy: +orivej

___
Python tracker 

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

[issue32696] Fix pickling exceptions with multiple arguments

2018-10-11 Thread Orivej Desh



Change by Orivej Desh :


--
nosy: +orivej

___
Python tracker 

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

[issue34959] Are the tests optional on travis?


New submission from Stéphane Wirtel :

In the config of Travis, we can see there is a OPTIONAL=true env var for the 
tests at line 72:

https://github.com/python/cpython/blob/master/.travis.yml#L72

If I read the doc, normally the tests can crash and this is not a problem?

Is it right, because I am not an expert of Travis.

Thank you,

Stéphane

--
messages: 327533
nosy: matrixise
priority: normal
severity: normal
status: open
title: Are the tests optional on travis?

___
Python tracker 

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

[issue34958] urllib.error.HTTPError.fp is not closed when error is finalized on Windows

2018-10-11 Thread Xiao Di Guan



New submission from Xiao Di Guan :

Following changes introduced in bpo-15002, HTTPError closes its fp when GCed 
via tempfile._TemporaryFileCloser's finalizer. However, the current 
implementation of _TemporaryFileCloser only defines __del__ for non-NT 
platforms.

Assuming HTTPError.fp is part of the API (though it's currently undocumented), 
and assuming the desired behaviour is to close fp when HTTPError is finalized, 
then perhaps _TemporaryFileCloser should always define __del__?

A contrived example follows:

```
from urllib.error import HTTPError
from urllib.request import urlopen

def make_request():
try:
urlopen('https://httpbin.org/status/418')
assert False
except HTTPError as err:
assert err.code == 418
return err.fp

fp = make_request()
assert fp.isclosed()  # Fails on Windows, passes on other platforms
```

--
components: Library (Lib)
messages: 327532
nosy: puxlit
priority: normal
severity: normal
status: open
title: urllib.error.HTTPError.fp is not closed when error is finalized on 
Windows
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

[issue29427] Option to skip padding for base64 urlsafe encoding/decoding

2018-10-11 Thread Mayank Asthana



Change by Mayank Asthana :


--
nosy: +masthana

___
Python tracker 

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

[issue29427] Option to skip padding for base64 urlsafe encoding/decoding

2018-10-11 Thread Xiao Di Guan



Change by Xiao Di Guan :


--
nosy: +puxlit

___
Python tracker 

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

[issue2142] difflib.unified_diff(...) produces invalid patches

2018-10-11 Thread Xiao Di Guan



Change by Xiao Di Guan :


--
nosy: +puxlit

___
Python tracker 

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

Re: how to replace line on particular line in file[no need to write it back whole file again]

2018-10-11 Thread Thomas Jollans

On 2018-10-11 11:44, Iranna Mathapati wrote:
> Hi Team,
> 
> How to replace particular line text with  new text on a file
> i have below code but its writing whole code.
> 
> def replace_line(file_name, line_num, text):
> lines = open(file_name, 'r').readlines()
> lines[line_num] = text
> out = open(file_name, 'w')
> out.writelines(lines)  < *writing back whole file instead of
> particular line*
> out.close()
> replace_line('stats.txt', 0, 'good')
> 
> 
> Thanks,
> Iranna M
> 

Can't be done.

There's no easy way to write to the middle of a file (though I think it
can be done by mmap'ing a file) -- and even if you manage to do that,
you'd have to write back anything after the changed line if the length
of that line changed by as little as a byte.

If you really want, you can avoid writing back anything *before* your
change by carefully using truncate():

def replace_line(file_name, line_num, new_text):
# Use a with statement to make sure the file is closed
with open(file_name, 'r+') as f:
# Ignore the first (line_num) lines
for _ in range(line_num):
f.readline()

# Save position, skip the line to be replaced
line_start = f.tell()
f.readline()

# We're keeping the rest of the file:
remaining_content = f.read()

# Chop off the file's tail!
f.seek(line_start)
f.truncate()

# Write the new tail.
if not new_text.endswith('\n'):
new_text = new_text + '\n'
f.write(new_text)
f.write(remaining_content)

That works, but your solution is more elegant.* This solution might make
sense for fairly large files where you can guarantee that the change
will be near the end.

* though you should close the file after you read it, preferable using a
with statement.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: From Mathematica to Jypyter

2018-10-11 Thread Rhodri James


On 10/10/18 17:24, jfine2...@gmail.com wrote:

Rhodri James wrote:

Robin Becker wrote:



I'm a great fan of erroneous spelling and this blog needs a spelling
check as this quote shows


[Paul Romer's blog]

"Mathematica exemplifies the horde of new Vandals whose pursuit of
private gain threatens a far greater pubic loss–the collapse of social
systems that took centuries to build."



these Vandals are probably not in favour of the #me-too movement either :)



OK, colour me confused.  The only spelling mistake I can spot in that is
in the subject line of this thread.  What am I missing?


In addition to Jypyter for Jupyter, there are TWO typos above. One in
Paul Romer's blog, followed by one in Robin Becker's comment.


Ah, the missing l, now I see it.

--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Observations on the List - "Be More Kind"

2018-10-11 Thread Rhodri James


On 10/10/18 19:14, Ethan Furman wrote:

On 10/10/2018 11:07 AM, Rhodri James wrote:

Now I've had a chance to go back through the archive (it's been that 
kind of day at work), I'm going to have to recant.  I can't find 
anything that Rick wrote in the week or two before the ban


Where are you looking?


https://mail.python.org/pipermail/python-list
specifically the June and July archives.  I wouldn't be surprised if 
those aren't complete; there's at least one post of mine I can't find there.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

[issue32153] mock.create_autospec fails if an attribute is a partial function

2018-10-11 Thread Berker Peksag



Berker Peksag  added the comment:

Yes, it would be great if we could convert the snippet in msg307115 to a test 
case before closing this issue. 3.6 still has this bug, but since we are pretty 
close to the end of its bugfix maintenance period, we can skip it.

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

[issue34957] Segementation faults on ARM and ARM64



Stefan Rink  added the comment:

* (re)installed libffi but it was already version 3.2.1.
* Currently compiling python3.7 on both ARM and AARCH64 to test them.
This may take a while because I need to install dask again for 3.7 to test.. 

Didn't try this on Linux ARM yet so I'll also try that.

Ps. If someone wants to try a fix or something but doesn't have access to ARM64 
hardware give me a notice; you can try it on one of my sopine nodes, pine64 or 
on a raspberry.

--

___
Python tracker 

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

[issue32153] mock.create_autospec fails if an attribute is a partial function

2018-10-11 Thread Karthikeyan Singaravelan



Karthikeyan Singaravelan  added the comment:

I think the original error has been fixed with issue28919 where the attribute 
errors are ignored while copying the functions as suggested by Anthony in 
solution 2. So can this issue be closed as outdated to reopen a new one for 
using update_wrapper as enhancement or the title can be changed to reflect the 
fact that autospec should now use update_wrapper instead of using 
_copy_func_details ? Correct me if I am wrong on the workflow to update the 
ticket.

Also there doesn't seem to be any test for this that can possibly added.

Current implementation : 

def _copy_func_details(func, funcopy):
# we explicitly don't copy func.__dict__ into this copy as it would
# expose original attributes that should be mocked
for attribute in (
'__name__', '__doc__', '__text_signature__',
'__module__', '__defaults__', '__kwdefaults__',
):
try:
setattr(funcopy, attribute, getattr(func, attribute))
except AttributeError:
pass


Thanks

--

___
Python tracker 

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

[issue34957] Segementation faults on ARM and ARM64



STINNER Victor  added the comment:

Is it possible that this bug is a duplicate of bpo-29804?

Would you be able to test Python 3.7.1RC1?

Sadly, this issue says "OK, PR 1559 (in 3.7.0) for Issue30353 has been 
backported to 3.6 in PR 5954 for release in 3.6.5".

I know that FreeBSD uses our bundled copy of libffi. I'm not sure that the copy 
in the 3.6 branch contains latest fixes for ARM64 :-( It seems to be libffi 
3.1. The latest version is libffi-3.2.1 ("released on November 12, 2014": no 
release for 4 days?) on https://sourceware.org/libffi/

--
nosy: +vstinner

___
Python tracker 

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

how to replace line on particular line in file[no need to write it back whole file again]

2018-10-11 Thread Iranna Mathapati

Hi Team,

How to replace particular line text with  new text on a file
i have below code but its writing whole code.

def replace_line(file_name, line_num, text):
lines = open(file_name, 'r').readlines()
lines[line_num] = text
out = open(file_name, 'w')
out.writelines(lines)  < *writing back whole file instead of
particular line*
out.close()
replace_line('stats.txt', 0, 'good')


Thanks,
Iranna M
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue34957] Segementation faults on ARM and ARM64



New submission from Stefan Rink :

When trying to run dask distributed on ARM you will end with a segmentation 
fault on multiple in multiple tests;

Works on AMD64 but does not work on ARM or AARCH64 and results in a Signal 11.

Example;
# python
Python 3.6.6 (default, Sep 29 2018, 05:50:41) 
[GCC 4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)] on 
freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>> from dask.distributed import Client
>>> client = Client()
Segmentation fault (core dumped)

# gdb /usr/local/bin/python3.6 python3.6.core 
GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "aarch64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/python3.6...(no debugging symbols 
found)...done.
[New LWP 101213]
Core was generated by `python'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  testcancel (curthread=0x3e8) at /usr/src/lib/libthr/thread/thr_cancel.c:144
144 {
(gdb) bt
#0  testcancel (curthread=0x3e8) at /usr/src/lib/libthr/thread/thr_cancel.c:144
#1  _thr_cancel_enter (curthread=0x3e8) at 
/usr/src/lib/libthr/thread/thr_cancel.c:146
#2  0x402a5b54 in __thr_connect (fd=3, name=0xd310, namelen=106)
at /usr/src/lib/libthr/thread/thr_syscalls.c:179
#3  0x4240e23c in uuid_generate_time () from /usr/local/lib/libuuid.so.1
#4  0x42382068 in ffi_call_SYSV () from /lib/libffi.so.6
#5  0x423822c8 in ffi_call () from /lib/libffi.so.6
#6  0x4234664c in _ctypes_callproc () from 
/usr/local/lib/python3.6/lib-dynload/_ctypes.so
#7  0x423403f0 in ?? () from 
/usr/local/lib/python3.6/lib-dynload/_ctypes.so
#8  0x422f5720 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

--
components: Build, Cross-Build, FreeBSD, ctypes
messages: 327527
nosy: Alex.Willmer, koobs, stefanr...@yahoo.com
priority: normal
severity: normal
status: open
title: Segementation faults on ARM and ARM64
type: crash
versions: Python 2.7, 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: From Mathematica to Jypyter

2018-10-11 Thread Thomas Jollans

On 2018-10-11 10:48, jfine2...@gmail.com wrote:
> It is fun to find fault in the work of a new Nobel laureate. In this case, a 
> typo.

Not a Nobel laureate. It's not a Nobel prize.

> 
> However, I'm disappointed that no-one has picked up the other error. Someone 
> posted to this thread "the #me-too movement". It should be "#MeToo".
> 
> Yes, I know it's CamelCase. I think that's actually Pythonic. It's the name 
> for a class of messages.
> 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: From Mathematica to Jypyter

2018-10-11 Thread jfine2358

It is fun to find fault in the work of a new Nobel laureate. In this case, a 
typo.

However, I'm disappointed that no-one has picked up the other error. Someone 
posted to this thread "the #me-too movement". It should be "#MeToo".

Yes, I know it's CamelCase. I think that's actually Pythonic. It's the name for 
a class of messages.

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

Problems installing RStudio from Anaconda Navigator

2018-10-11 Thread Spencer Graves

  I clicked "Install" for "RStudio 1.1.456" in Anaconda Navigator 
1.9.2 under Windows 7 Home Premium SP1.  It said "Installing application 
RStudio" for over 30 minutes.  It looked stuck.



  Then I read a GitHub post that said, "On the environments tab 
create a new R/Python3.5 environment", then install RStudio into that 
new environment.[1]



  So I killed the RStudio install and looked at the "Environments 
tab".  I'm new to Anaconda Navigator, and I didn't know what I was 
looking at so decided to ask here.



  Suggestions?


  Thanks,
  Spencer Graves


p.s.  I do not currently have RStudio installed on that machine.  On a 
macOS 10.13.6 machine, I have have RStudio 1.2.792 on a macOS 10.13.6.  
Anaconda Navigator 1.9.2 on my Mac fails to recognize the existing and 
more recent installation of RStudio 1.2.792 there. Should I, e.g., try 
to "Import" that existing RStudio installation?



[1] https://github.com/conda/conda/issues/4204
--
https://mail.python.org/mailman/listinfo/python-list

[issue34576] [EASY doc] http.server, SimpleHTTPServer: warn users on security


STINNER Victor  added the comment:

The render is surprising: it looks like the full documentation is part of the § 
Security Considerations:

https://docs.python.org/dev/library/http.server.html#security-considerations

I suggest to add a new title for the rest of the documentation.

--

___
Python tracker 

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

[issue34954] Getting an email's subject is error-prone

2018-10-11 Thread Alex Corcoles


Alex Corcoles  added the comment:

Well, I think that having to choose the "HTTP" policy to get a message 
subject's without newlines goes against the expectations of anyone who is not 
well knowledgeable of email.

It's not very easy to deduct that, out of all the available policies, HTTP is 
the one that has this effect (or writing your own).

It's not obvious that a subject can have newlines, as I don't think I've ever 
seen a MUA that does not hide them.

You can be bitten quite easily by that (we have, more than once).

It's the stdlib's maintainers' prerrogative to decide that they are going to 
provide low-level libraries (and in general, I agree with that, high-level 
stdlibs have a lot of problems), but at least I'd include some warning like:

"Email is an old and annoying protocol, and parsing email is full of annoyances 
and exceptions. email provides low-level building blocks to handle email in 
detail. If you want high-level processing we advise you to look at libraries 
that build on it".

In any case, email.policy provides more hints as to headers being wordwrapped, 
and while it's not ideal, it certainly is an improvement WRT to Python 2, so 
this bug has helped me and I hope maybe someone will read it when Googling for 
the same problem, so while I think some more could be done, if you close this I 
won't complain.

Thanks,

Álex

--
status: closed -> open

___
Python tracker 

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

Re: ESR "Waning of Python" post

On Thu, Oct 11, 2018 at 6:43 PM Thomas Jollans  wrote:
> The gist is that the GIL is a problem only for relatively few problems
> (e.g. games that need limited-scale low-latency parallelism). Most of
> the time, you either only need one process in the first place, or you
> can take full advantage of your multi-core machine, or multiple
> multi-core machines, using multiple processes (with ipyparallel or whatever)

Right. If someone goes on a long rant saying how he wasn't able to
write his device driver in Python, and he's giving up on the language
and going to C, would that be taken as an affront to Python, or the
knell of the language, or anything like that? No, it'd be "well,
that's not Python's role". But if someone needs to manage a billion
teensy sub-jobs and then finds that Python is unsuitable, it's clearly
the GIL's fault, and this is a fundamental flaw in the language, and
we should all move to Go for all our coding because Python utterly
sucks. Why? Why not just let other languages do things differently,
and have other design tradeoffs?

This is one fairly specific class of problem which is poorly served by
Python's/CPython's design. (I'm not sure how much of this could be
done differently in an alternative implementation; so far, we haven't
seen a "Python for embarrassingly parallel problems" implementation,
so I suspect part of it is language design.) So pick a different
language *for those problems*.

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

[issue34956] _tkinter built on macOS 10.14 does not link to Tcl and Tk in /Library/Frameworks



Ned Deily  added the comment:

Correction: in the original second paragraph, the fourth sentence obviously has 
the case backwards.  It should read:

"When using a *Command Line Tools installation (no Xcode)* in previous releases 
of macOS, I believe it was the case that essentially the system root directory 
('/') was searched by the compiler tool chain for header files, for libraries, 
and for frameworks, and for frameworks the long standard fallback framework 
search path order was honored by default: first search /Library/Frameworks, 
then /System/Library/Frameworks. [...]"

--

___
Python tracker 

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

[issue21880] IDLE: Ability to run 3rd party code checkers

2018-10-11 Thread Tal Einat



Change by Tal Einat :


--
pull_requests: +9185

___
Python tracker 

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

[issue21880] IDLE: Ability to run 3rd party code checkers

2018-10-11 Thread Tal Einat



Tal Einat  added the comment:

See PR9802.

--

___
Python tracker 

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

Re: ESR "Waning of Python" post

2018-10-11 Thread Thomas Jollans


On 11/10/2018 09:11, Ben Finney wrote:

Chris Angelico  writes:


In actual fact, it's not a problem per-se. It's a design choice, and
every alternative choice tried so far has even worse problems. THAT is
why we still have it.


That reads to me like a rejection of the point made in the blog post:
that the GIL prevents Python from taking proper advantage of multi-core
machines.

In other words: Yes, it's a design decision, but that design decision
causes the problems described.

Is it your position that the described behaviour is not a problem? Do
you hold that position because you think multi-core machines are not a
sector that Python needs to be good at? Or that the described behaviour
doesn't occur? Or something else?



I recently watched this talk by Raymond Hettinger on concurrency which 
gives some perspective on this question especially in the first ten 
minutes: https://www.youtube.com/watch?v=9zinZmE3Ogk


The gist is that the GIL is a problem only for relatively few problems 
(e.g. games that need limited-scale low-latency parallelism). Most of 
the time, you either only need one process in the first place, or you 
can take full advantage of your multi-core machine, or multiple 
multi-core machines, using multiple processes (with ipyparallel or whatever)

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

[issue34956] _tkinter built on macOS 10.14 does not link to Tcl and Tk in /Library/Frameworks

Ned Deily added the comment:

macOS 10.14 appears to have introduced some subtle differences in the search
order for finding header files and/or frameworks and libraries. I'm not 100%
sure I understand completely what has changed but I'm confident that the
workaround outlined below should get you going until we have a better solution
(but beware of the potential gotcha).

Python has never fully supported building only from an Xcode-only installation,
i.e. we have required at a minimum installing system header files into
/usr/include et al by using "xcode-select --install". As of 10.14,
xcode-select no longer installs header files in /usr/include. So that further
cripples Python builds in that header files for several third-party libraries
shipped with macOS are no longer found, like zlib and sqlite3. When using an
Xcode-only installation (no Command Line Tools) in previous releases of macOS,
I believe it was the case that essentially the system root directory ('/') was
searched by the compiler tool chain for header files, for libraries, and for
frameworks, and for frameworks the long standard fallback framework search path
order was honored by default: first search /Library/Frameworks, then
/System/Library/Frameworks. That worked fine if you were installing frameworks
like Tcl and TK into /Library/Frameworks and wanting them to override the system
ones. If you did not install the Command Line Tools, then the tool chain
used the MacOSX.sdk embedded in Xcode.app as the system root for searching. By
default, that's found in:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

With an unmodified Xcode install, that directory contains usr and System
directories but no Library. So the contents of /Library were ignored by the
tool chain with the net effect that _tkinter builds would also link with the
Apple-supplied Tcl and Tk 8.5 in /System/Library/Frameworks.

With 10.14, Xcode-only installs still work the same way but now Command Line
Tools seem to effectively use the SDK embedded in
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk as the system root, rather
than the system /. Just like the Xcode copy of the sdk, the CLT copy does not
have a Library directory so now the results are the same as Xcode-only builds:
_tkinter only links with the /System/Library Tcl and Tk. From the viewpoint of
developers trying to build applications for distribution to others, it makes
sense to try to ensure that /Library does not influence the build because
/Library is under user control, not the system (Apple).

Until we "recently" started shipping our private version of Tcl and Tk 8.6.x,
which we do not install to /Library btw, it made sense to default to linking to
/Library and falling back to /System/Library, allowing optional use of a
third-party Tcl/Tk (like from ActiveState) and it all sort of worked if you
used the tool chain from the CLT. But with 10.14, that no longer works.
Python's build system complicates this all in large part because the top-level
setup.py tries to guess what directories the compiler tool chain are going to
search; that was always kind of iffy and now it's much more broken with macOS
10.14. There are ways to work around most of the issues but we need to have
better default behavior. That's kind of a bigger deal.

For the specific case of building _tkinter to link with Tcl and Tk frameworks
in /Library, I think the easiest workaround is to add a Library symlink to the
SDK in use, either under /Library/Developer/CommandTools or
/Applications/Xcode.app. "xcode-select --print-path" will show which one is in
use, but, alas, not the full path to the SDK.

either:
$ xcode-select --print-path
/Library/Developer/CommandLineTools
$ cd /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/

or:
$ xcode-select --print-path
/Applications/Xcode.app/Contents/Developer
$ xcodebuild -version -sdk macosx Path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
$ cd $(xcodebuild -version -sdk macosx Path)

You can then carefully create a symlink from the SDK to /Library.

$ sudo ln -s /Library .

Now the Python builds should find the Current version of Tcl and Tk frameworks
in /Library.

*But* be aware that this might affect other builds if there are other
frameworks you have installed in /Library. So this workaround should be used
with caution and you might consider removing the symlink once you are done
building Python.

There are other, more complicated workarounds but this seems to me to be the
simplest and most foolproof as long as one is aware of the risks and is
prepared to potentially recreate the Library symlink after software updates to
Xcode or the Command Line Tools.

--
assignee: -> ned.deily
priority: normal -> high
title: 3.7.0 _tkinter module links against /System/Library/Frameworks ->
_tkinter built on macOS 10.14 does not link

Re: ESR "Waning of Python" post

On Thu, Oct 11, 2018 at 6:12 PM Ben Finney  wrote:
>
> Chris Angelico  writes:
>
> > In actual fact, it's not a problem per-se. It's a design choice, and
> > every alternative choice tried so far has even worse problems. THAT is
> > why we still have it.
>
> That reads to me like a rejection of the point made in the blog post:
> that the GIL prevents Python from taking proper advantage of multi-core
> machines.
>
> In other words: Yes, it's a design decision, but that design decision
> causes the problems described.
>
> Is it your position that the described behaviour is not a problem? Do
> you hold that position because you think multi-core machines are not a
> sector that Python needs to be good at? Or that the described behaviour
> doesn't occur? Or something else?

Multi-core machines are important, but even on multi-core machines,
most Python processes don't need more than one. AFAIK, every single
alternative to the GIL has resulted in a measurable performance
penalty when running on a single core. (Happy to be proven wrong if
that's not the case.) So if you want better multi-core performance,
you MUST accept a single-core penalty.

Frankly, I don't see a problem with saying "Python doesn't make it
easy to write code that floods eight cores with work, therefore I will
choose a different language for this job". It doesn't mean Python is a
bad language. It just means that Python is not the one and only
language that all code must forever be written in.

There's a huge difference between deciding on using some different
language for a project, and going on a massive ire-filled rant.

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

Re: ESR "Waning of Python" post

2018-10-11 Thread Ben Finney

Chris Angelico  writes:

> In actual fact, it's not a problem per-se. It's a design choice, and
> every alternative choice tried so far has even worse problems. THAT is
> why we still have it.

That reads to me like a rejection of the point made in the blog post:
that the GIL prevents Python from taking proper advantage of multi-core
machines.

In other words: Yes, it's a design decision, but that design decision
causes the problems described.

Is it your position that the described behaviour is not a problem? Do
you hold that position because you think multi-core machines are not a
sector that Python needs to be good at? Or that the described behaviour
doesn't occur? Or something else?

-- 
 \  “A hundred times every day I remind myself that […] I must |
  `\   exert myself in order to give in the same measure as I have |
_o__)received and am still receiving” —Albert Einstein |
Ben Finney

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

[issue34095] [2.7] test_idle fails with: /usr/bin/xvfb-run: line 181: 3617 Segmentation fault

2018-10-11 Thread Chih-Hsuan Yen



Chih-Hsuan Yen  added the comment:

Here is partial backtrace from commit 1d26c72e6a9c5b28b27c158f2f196217707dbb0f:

#0  0x76763197 in GetTkFontAttributes 
(faPtr=faPtr@entry=0x55cd91e8, ftFont=)
at /usr/src/debug/tk8.6.8/unix/../unix/tkUnixRFont.c:167
#1  0x767639fa in InitFont (tkwin=tkwin@entry=0x55ee94a0, 
pattern=pattern@entry=0x55cfc690, fontPtr=0x55cd91b0, 
fontPtr@entry=0x0) at /usr/src/debug/tk8.6.8/unix/../unix/tkUnixRFont.c:313
#2  0x76763c4e in TkpGetFontFromAttributes 
(tkFontPtr=tkFontPtr@entry=0x0, tkwin=tkwin@entry=0x55ee94a0, 
faPtr=0x55d1e8b8) at 
/usr/src/debug/tk8.6.8/unix/../unix/tkUnixRFont.c:482
#3  0x766b5ee2 in Tk_AllocFontFromObj (interp=0x55c4b900, 
tkwin=tkwin@entry=0x55ee94a0, objPtr=0x55e39000)
at /usr/src/debug/tk8.6.8/unix/../generic/tkFont.c:1158
#4  0x766ac053 in DoObjConfig (interp=interp@entry=0x55c4b900, 
recordPtr=recordPtr@entry=0x55e53390 "0r\354UUU", 
optionPtr=optionPtr@entry=0x55f4e010, valuePtr=, 
valuePtr@entry=0x55e39000, 
tkwin=tkwin@entry=0x55ee94a0, savedOptionPtr=savedOptionPtr@entry=0x0) 
at /usr/src/debug/tk8.6.8/unix/../generic/tkConfig.c:717
#5  0x766ace92 in Tk_InitOptions (interp=interp@entry=0x55c4b900, 
recordPtr=recordPtr@entry=0x55e53390 "0r\354UUU", 
optionTable=optionTable@entry=0x55f4de10, tkwin=0x55ee94a0) at 
/usr/src/debug/tk8.6.8/unix/../generic/tkConfig.c:496
#6  0x767250b2 in CreateWidget (sharedPtr=0x55ec7230, 
tkwin=, interp=0x55c4b900, 
parent=, objc=, objv=) at 
/usr/src/debug/tk8.6.8/unix/../generic/tkText.c:664
#7  0x762efe16 in TclNRRunCallbacks () from /usr/lib/libtcl8.6.so
#8  0x767eba0c in Tkapp_Call (selfptr=0x740242b0, args=)
at /home/yen/Projects/cpython/Modules/_tkinter.c:1508

Looks more like a Tk issue than a CPython one.

For Arch Linux packagers: adding checkdepends=('ttf-font') to PKGBUILD can fix 
testing errors. Here's an example: 
https://github.com/archlinuxcn/repo/commit/e4de4598bccd44ba38c37854dc5edfb490dbe09a

--

___
Python tracker 

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

Re: ESR "Waning of Python" post