[issue30242] resolve undefined behaviour in struct

[Xiang Zhang]

Xiang Zhang added the comment:

> I think it is better to change the type of p to unsigned char.

Good advice.

--

___
Python tracker 

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

[issue29094] Regression in zipfile writing in 2.7.13

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
pull_requests:  -911

___
Python tracker 

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

Re: __getattribute__'s error is not available in __getattr__

[Chris Angelico]

On Wed, May 3, 2017 at 3:05 PM, Ethan Furman  wrote:
>> I was going to hardcode AttributeError, which would have made it more
>> obvious and simpler, but then a single-purpose decorator (and if you
>> do that, why not just wrap your code in try/except manually?).
>> Obviously for production it needs a codstring...
>
>
> Indeed?  I heard about them!  Seems they're going to drive cod pieces out of
> style.  ;)

I know, right? Never mind about a herring, try cutting down a tree
with a string of cod!

It even looks like a saw...

http://eastbournecharterfishing.com/images/cod-success.jpg

Apparently my fingers think that this belongs inside a function.

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

[issue29094] Regression in zipfile writing in 2.7.13

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

There is no explicit line, but offsets always are named relative: "relative 
offset of local header", "offset of start of central directory with respect to 
the starting disk number". This looks not pretty clear, but open source 
utilities (unzip, p7zip) support ZIP archives started not from the start of the 
file.

--

___
Python tracker 

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

[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX

[Nick Coghlan]

Nick Coghlan added the comment:

Noting a design consideration that I only picked up in the latest PR review: 
when exposed as part of a non-opaque struct, the type used for TSS keys becomes 
part of Python's ABI, which means the API design in the PEP is going to have to 
handle making the struct fully opaque when Py_LIMITED_API is defined.

My proposal for handling that:

- update all of the API functions to accept Py_tss_t by pointer rather than by 
value
- update the Py_tss_t definition to be an opaque struct when Py_LIMITED_API is 
defined
- add PyThread_tss_alloc and PyThread_tss_free functions for dynamic allocation 
of key storage (since static allocation won't be possible in the Py_LIMITED_API 
case)

My main rationale for going to that level of effort is that the current thread 
local storage API is available when Py_LIMITED_API is defined, so its 
replacement should be available as well. However, exposing NATIVE_TSS_KEY_T as 
part of the stable ABI would prevent us from switching from `int` to a platform 
specific implementation for platforms that start out using the generic 
emulation.

If issue #29881 ever became a public API, it would then be useful for managing 
the lifecycle of dynamically allocated TSS keys in extension modules that 
restrict themselves to the stable ABI.

--

___
Python tracker 

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

Re: getting memory usage of varaibles

[INADA Naoki]

I recommend tracemalloc.

Start with PYTHONTRACEMALLOC=3, and increase depth only when stack trace is
too short.

2017/05/03 午後0:50 "Larry Martell" :

> On Tue, May 2, 2017 at 7:01 PM, Erik  wrote:
> > On 02/05/17 23:28, Larry Martell wrote:
> 
>  Anyone have any thoughts on how I can monitor the variables' memory
>  usage as the script runs?
> >>>
> >>>
> >>> This is application-specific, but sometimes it helps to look at the
> >>> objects' types, or even their values.
> >>
> >>
> >> The types are dict and list, so they are not very useful, nor were the
> >> values.
> >
> >
> > Given your description, I would hazard a guess that you have a circular
> > reference somewhere (such that some objects may remain referenced after
> you
> > believe they should have been discarded). You could _probably_ break that
> > circle with some carefully placed 'del' statements somewhere - but you'd
> > need to analyze your data structures (and closures) first to see if
> that's
> > the case.
>
> This script is part of a django project, but it is not part of the
> core web django app. It's a stand alone script that is run from the
> command line. I added some profiling to the script and I found that
> the object count was increasing repidly with each loop (and of course
> with that the memory usage). I originally wrote it using the django
> ORM but now I have rewritten it using MySQLdb and embedded SQL. That
> stopped the increase in the object count and drastically reduced the
> memory leakage, but did not stop it. But at least now I can run it
> without it using all of the memory and getting killed. I'd still love
> to know where it's leaking memory, but I may not get the time for
> that.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30231] test_imaplib needs a TLS server accepting self-signed certificates

[Benjamin Peterson]

Benjamin Peterson added the comment:

I can't say I'm very interested in running a imap server. It would be best if 
these tests could be replaced by something local. Failing that, I suppose we'll 
have to remove them.

--

___
Python tracker 

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

[issue30242] resolve undefined behaviour in struct

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I think it is better to change the type of p to unsigned char.

--

___
Python tracker 

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

Re: __getattribute__'s error is not available in __getattr__

[Ethan Furman]

On 05/02/2017 09:57 PM, Chris Angelico wrote:

On Wed, May 3, 2017 at 2:39 PM, Ethan Furman  wrote:

On 05/02/2017 07:47 PM, Chris Angelico wrote:


On Wed, May 3, 2017 at 12:37 PM, Ethan Furman wrote:




Until then Chris' decorator is probably the easiest work around -- but
you
should only catch AttributeError, not everything.



It does. (Or rather, it catches only those exception(s) listed as
parameters.) Any other exceptions pass through unchanged.



Ah, that's what I get for skimming!


I was going to hardcode AttributeError, which would have made it more
obvious and simpler, but then a single-purpose decorator (and if you
do that, why not just wrap your code in try/except manually?).
Obviously for production it needs a codstring...


Indeed?  I heard about them!  Seems they're going to drive cod pieces out of 
style.  ;)

--
~Ethan~

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

[issue29447] Add os.PathLike support to the tempfile module

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

TemporaryDirectory and _TemporaryFileWrapper are *not* paths, as well as 
ordinal files are not paths. Adding __fspath__() to them looks wrong to me.

I think this isn't what Brett meant.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue29094] Regression in zipfile writing in 2.7.13

[Benjamin Peterson]

Benjamin Peterson added the comment:

Anything breaking 2.7 should be reverted. I take it, the change from #26293 
should be as well as this one?

Yhg1s, the commit message for #26293 included the sentence "Offsets in ZIP file 
now are relative to the start of the archive in conforming to the 
specification." Can someone point to the line in the spec that covers this?

--

___
Python tracker 

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

Re: getting memory usage of varaibles

[Chris Angelico]

On Wed, May 3, 2017 at 5:53 AM, Larry Martell  wrote:
> And I can see it getting larger and larger. But I want to see what it
> is that is causing this. My thought was to put all the objects in a
> dict with their sizes and compare them as the program runs and report
> on the one that are growing. But I can't get the name of the object
> from gc.get_objects only the id.

Coming right back to the beginning here: What do you expect the name
of an object to be?

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

Re: __getattribute__'s error is not available in __getattr__

[Chris Angelico]

On Wed, May 3, 2017 at 2:39 PM, Ethan Furman  wrote:
> On 05/02/2017 07:47 PM, Chris Angelico wrote:
>>
>> On Wed, May 3, 2017 at 12:37 PM, Ethan Furman wrote:
>
>
>>> Until then Chris' decorator is probably the easiest work around -- but
>>> you
>>> should only catch AttributeError, not everything.
>>
>>
>> It does. (Or rather, it catches only those exception(s) listed as
>> parameters.) Any other exceptions pass through unchanged.
>
>
> Ah, that's what I get for skimming!

I was going to hardcode AttributeError, which would have made it more
obvious and simpler, but then a single-purpose decorator (and if you
do that, why not just wrap your code in try/except manually?).
Obviously for production it needs a codstring...

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

Re: __getattribute__'s error is not available in __getattr__

[Ethan Furman]

On 05/02/2017 07:47 PM, Chris Angelico wrote:

On Wed, May 3, 2017 at 12:37 PM, Ethan Furman wrote:



Until then Chris' decorator is probably the easiest work around -- but you
should only catch AttributeError, not everything.


It does. (Or rather, it catches only those exception(s) listed as
parameters.) Any other exceptions pass through unchanged.


Ah, that's what I get for skimming!

--
~Ethan~

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

[issue30242] resolve undefined behaviour in struct

[Xiang Zhang]

Changes by Xiang Zhang :


--
pull_requests: +1524

___
Python tracker 

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

[issue30242] resolve undefined behaviour in struct

[Xiang Zhang]

New submission from Xiang Zhang:

In struct there are several places using code like:

  p[--i] = (char)x;

to extract the least significant byte from a long. Although this behaviour 
seems to apply to common implementations but it does not conform to C standard.

--
components: Library (Lib)
messages: 292836
nosy: mark.dickinson, meador.inge, serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: resolve undefined behaviour in struct
type: behavior
versions: Python 2.7, 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

[issue28556] typing.py upgrades

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
versions: +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

[issue28556] typing.py upgrades

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +1523

___
Python tracker 

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

[issue28556] typing.py upgrades

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +1522

___
Python tracker 

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

[issue30110] test_asyncio reports reference leak

[Xiang Zhang]

Changes by Xiang Zhang :


--
pull_requests: +1521

___
Python tracker 

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

[issue30241] Add contextlib.AbstractAsyncContextManager

[Jelle Zijlstra]

Changes by Jelle Zijlstra :


--
pull_requests: +1520

___
Python tracker 

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

[issue30241] Add contextlib.AbstractAsyncContextManager

[Jelle Zijlstra]

New submission from Jelle Zijlstra:

It would be useful to have an abstract base class for asynchronous context 
managers, similar to the existing contextlib.AbstractContextManager. We can 
then also add this class to typing and use it as a PEP 544 Protocol.

I have code ready for contextlib.AbstractAsyncContextManager and will submit 
the PR shortly. I'll also add support in typing and typeshed if the CPython 
change is accepted.

--
components: Library (Lib)
messages: 292835
nosy: Jelle Zijlstra, levkivskyi, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: Add contextlib.AbstractAsyncContextManager
type: enhancement
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

Re: getting memory usage of varaibles

[Larry Martell]

On Tue, May 2, 2017 at 7:01 PM, Erik  wrote:
> On 02/05/17 23:28, Larry Martell wrote:

 Anyone have any thoughts on how I can monitor the variables' memory
 usage as the script runs?
>>>
>>>
>>> This is application-specific, but sometimes it helps to look at the
>>> objects' types, or even their values.
>>
>>
>> The types are dict and list, so they are not very useful, nor were the
>> values.
>
>
> Given your description, I would hazard a guess that you have a circular
> reference somewhere (such that some objects may remain referenced after you
> believe they should have been discarded). You could _probably_ break that
> circle with some carefully placed 'del' statements somewhere - but you'd
> need to analyze your data structures (and closures) first to see if that's
> the case.

This script is part of a django project, but it is not part of the
core web django app. It's a stand alone script that is run from the
command line. I added some profiling to the script and I found that
the object count was increasing repidly with each loop (and of course
with that the memory usage). I originally wrote it using the django
ORM but now I have rewritten it using MySQLdb and embedded SQL. That
stopped the increase in the object count and drastically reduced the
memory leakage, but did not stop it. But at least now I can run it
without it using all of the memory and getting killed. I'd still love
to know where it's leaking memory, but I may not get the time for
that.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30103] uu package uses old encoding

[Xiang Zhang]

Changes by Xiang Zhang :


--
resolution:  -> fixed
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

[issue30103] uu package uses old encoding

[Xiang Zhang]

Xiang Zhang added the comment:


New changeset 13f1f423fac39f8f14a3ce919dd236975517d5c6 by Xiang Zhang in branch 
'master':
bpo-30103: Allow Uuencode in Python using backtick as zero instead of space 
(#1326)
https://github.com/python/cpython/commit/13f1f423fac39f8f14a3ce919dd236975517d5c6


--

___
Python tracker 

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

[issue29447] Add os.PathLike support to the tempfile module

[svelankar]

Changes by svelankar :


--
nosy: +svelankar

___
Python tracker 

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

[issue29447] Add os.PathLike support to the tempfile module

[svelankar]

Changes by svelankar :


--
pull_requests: +1519

___
Python tracker 

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

[issue30240] Add daemon keyword argument to Thread constructor

[Zachary Ware]

Zachary Ware added the comment:

It's already there: 
https://docs.python.org/3/library/threading.html#threading.Thread

--
nosy: +zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

[issue30240] Add daemon keyword argument to Thread constructor

[TaoQingyun]

Changes by TaoQingyun <845767...@qq.com>:


--
versions: +Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

[issue30240] Add daemon keyword argument to Thread constructor

[TaoQingyun]

New submission from TaoQingyun:

create a daemon thread like this,  
```
t = Thread(target=f)
t.daemon = True
t.start()
```

I wonder the following code is better
```
Thread(target=f, daemon=True).start()
```

--
components: Library (Lib)
messages: 292832
nosy: qingyunha
priority: normal
severity: normal
status: open
title: Add daemon keyword argument to Thread constructor
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

Re: __getattribute__'s error is not available in __getattr__

[Chris Angelico]

On Wed, May 3, 2017 at 12:37 PM, Ethan Furman  wrote:
> Until then Chris' decorator is probably the easiest work around -- but you
> should only catch AttributeError, not everything.

It does. (Or rather, it catches only those exception(s) listed as
parameters.) Any other exceptions pass through unchanged.

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

Re: __getattribute__'s error is not available in __getattr__

[Ethan Furman]

On 05/02/2017 05:59 PM, Jason Maldonis wrote:


@Steve they asked me to move it here because it was more fitting. I hope that's 
okay?


Yes, it's okay.  ;)


After some testing, it looks like I'm okay with how things work if the 
problem-object isn't a descriptor (although I do
still things it's a bit odd that an error gets squashed, but it's no big deal).

However, I use @property all the time, so that's likely why I'm running into 
this so often.  If you can help explain to
me what's going on in that case, that would be great!  I have two examples 
below for the sake of discussion.

Here's an example where the underlying error is completely hidden:

class A(object):
 def _some_complex_code_hidden_from_the_user(self):
 # Run a bunch of complex stuff that raises an attribute error 
internally
 # This could go layers deep into different modules
 return self.this_doesnt_exist

 @property
 def x(self):
 return self._some_complex_code_hidden_from_the_user()

 def __getattr__(self, attr):
 raise AttributeError("raised from A.__getattr__ to stop execution")

a = A()
print(a.x)


This results in the following output:

Traceback (most recent call last):
   File "test3.py", line 17, in 
 print(a.x)
   File "test3.py", line 14, in __getattr__
 raise AttributeError("raised from A.__getattr__ to stop execution")
AttributeError: raised from A.__getattr__ to stop execution


Here the real reason the code errors (`sys.this_doesnt_exist` throwing an 
AttributeError) is not in the traceback's stack.


The problem is that Python cannot tell the difference between `A.x` not existing (which would raise AttributeError), and 
some attribute inside `A.x` not existing (which also raises AttributeError).


There's an issue to fix this somewhere in the Python Bug Tracker (bugs.python.org) but I cannot find it at the moment 
(it's quite old).



My current opinion on this is that the error that triggered __getattr__ should 
be passed to __getattr__. This would
allow us to use the "raise from" syntax.


Hmm.  Since the other issue isn't making any headway this might be the best we get -- you should open a thread for it 
over at Python Ideas.  :)


Until then Chris' decorator is probably the easiest work around -- but you 
should only catch AttributeError, not everything.

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

[issue28326] multiprocessing.Process depends on sys.stdout being open

[Tiago Antao]

Changes by Tiago Antao :


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

[issue28326] multiprocessing.Process depends on sys.stdout being open

[Tiago Antao]

Changes by Tiago Antao :


--
pull_requests: +1515

___
Python tracker 

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

Re: __getattribute__'s error is not available in __getattr__

[Chris Angelico]

On Wed, May 3, 2017 at 10:59 AM, Jason Maldonis  wrote:
> Here's an example where the underlying error is completely hidden:
>
> class A(object):
> def _some_complex_code_hidden_from_the_user(self):
> # Run a bunch of complex stuff that raises an attribute error
> internally
> # This could go layers deep into different modules
> return self.this_doesnt_exist
>
> @property
> def x(self):
> return self._some_complex_code_hidden_from_the_user()
>
> def __getattr__(self, attr):
> raise AttributeError("raised from A.__getattr__ to stop execution")
>
> a = A()
> print(a.x)
>
>
> This results in the following output:
>
> Traceback (most recent call last):
>   File "test3.py", line 17, in 
> print(a.x)
>   File "test3.py", line 14, in __getattr__
> raise AttributeError("raised from A.__getattr__ to stop execution")
> AttributeError: raised from A.__getattr__ to stop execution

AIUI, the problem here is that a property function that leaks an
AttributeError looks like a missing property and calls __getattr__. Is
that correct?

What you could do is put in a little guard decorator. Basically, mark
this function as "should never raise AttributeError":

def wont_raise(*exc):
def deco(func):
@functools.wraps(func)
def wrapper(*a, **kw):
try:
return func(*a, **kw)
except exc as e:
raise RuntimeError("Faulty exception raised") from e
# Note that in Py2, you may want manual exception chaining
# to avoid losing the original (this uses Py3's __cause__).
return wrapper
return deco

class A:
@property
@wont_raise(AttributeError)
def x(self):
return self._x
def __getattr__(self, attr):
raise AttributeError("raised from A.__getattr__ to stop execution")

>>> A().x
Traceback (most recent call last):
  File "", line 6, in wrapper
  File "", line 5, in x
  File "", line 7, in __getattr__
AttributeError: raised from A.__getattr__ to stop execution

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "", line 1, in 
  File "", line 8, in wrapper
RuntimeError: Faulty exception raised

You now have the entire exception traceback.

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

[issue30233] [3.5] Warning -- locale was modified by test_idle

[Terry J. Reedy]

Terry J. Reedy added the comment:

Victor, I forgot to ask.  Did you properly test IDLE before committing the 
patch?  This means building python 3.5, starting IDLE, and exercising the 
modules affected.  test_idle is nowhere nearly a substitute for such 
hand-testing.  This is a big part of the 'bother' I referred to.

--

___
Python tracker 

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

[issue30199] Warning -- asyncore.socket_map was modified by test_ssl

[STINNER Victor]

STINNER Victor added the comment:


New changeset d1c862ffa73b222746035155817d2516c4f5b71e by Victor Stinner in 
branch '2.7':
bpo-30199: test_ssl closes all asyncore channels (#1381) (#1408)
https://github.com/python/cpython/commit/d1c862ffa73b222746035155817d2516c4f5b71e


--

___
Python tracker 

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

[issue30199] Warning -- asyncore.socket_map was modified by test_ssl

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +1514

___
Python tracker 

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

Re: __getattribute__'s error is not available in __getattr__

[Jason Maldonis]

@Steve they asked me to move it here because it was more fitting. I hope
that's okay?


After some testing, it looks like I'm okay with how things work if the
problem-object isn't a descriptor (although I do still things it's a bit
odd that an error gets squashed, but it's no big deal).

However, I use @property all the time, so that's likely why I'm running
into this so often.  If you can help explain to me what's going on in that
case, that would be great!  I have two examples below for the sake of
discussion.

Here's an example where the underlying error is completely hidden:

class A(object):
def _some_complex_code_hidden_from_the_user(self):
# Run a bunch of complex stuff that raises an attribute error
internally
# This could go layers deep into different modules
return self.this_doesnt_exist

@property
def x(self):
return self._some_complex_code_hidden_from_the_user()

def __getattr__(self, attr):
raise AttributeError("raised from A.__getattr__ to stop execution")

a = A()
print(a.x)


This results in the following output:

Traceback (most recent call last):
  File "test3.py", line 17, in 
print(a.x)
  File "test3.py", line 14, in __getattr__
raise AttributeError("raised from A.__getattr__ to stop execution")
AttributeError: raised from A.__getattr__ to stop execution


Here the real reason the code errors (`sys.this_doesnt_exist` throwing an
AttributeError) is not in the traceback's stack.

My current opinion on this is that the error that triggered __getattr__
should be passed to __getattr__. This would allow us to use the "raise
from" syntax.


Here's an example where I manually fix this for a specific class:

class A(object):
def _some_complex_code_hidden_from_the_user(self):
# a bunch of complex stuff that raises an attribute error internally
# This could go layers deep into different modules
return self.this_doesnt_exist

@property
def x(self):
return self._some_complex_code_hidden_from_the_user()

def __getattribute__(self, attr):
try:
return super().__getattribute__(attr)
except AttributeError as error:
return self.__custom_getattr__(attr, error)

def __custom_getattr__(self, attr, error):
raise AttributeError("raised from A.__getattr__ to stop execution")
from error

#def __getattr__(self, attr):
#raise AttributeError("raised from A.__getattr__ to stop
execution") from error

a = A()
print(a.x)

This code correctly prints `AttributeError: module 'sys' has no attribute
'this_doesnt_exist'` because I `raise from error`.

Note that __getattr__ can't be defined;  if it is, it will squash the error
message from __custom_getattr__ analogous to what's going on in the first
example.

More importantly, note that __getattribute__ can't just `return
self.__getattr__(attr)` in its except block because __getattribute__ isn't
supposed to directly call __getattr__ (because __getattr__ gets triggered
later in the python attribute lookup order).

Unfortunately, this behavior is not generalizable without overriding
__getattribute__ and defining __custom_getattr__ on every single class in
the inheritance structure if I wanted it work for each class.


The 2nd example is the behavior I desire, and I don't really understand how
the descriptor figures into this problem to change that behavior.  -- I.e.
if you just remove @property from the first example, it returns the full
error stack exactly like we'd expect. That means the @property is changing
the call order (?) in some way that I don't understand.

Thanks!
Jason



On Tue, May 2, 2017 at 7:11 PM, Ethan Furman  wrote:

> On 05/02/2017 11:16 AM, Jason Maldonis wrote:
>
> Here is the simplest example showing what I mean (there are many more
>> complicating variations this, and unfortunately I'm running into some of
>> them):
>>
>> class A(object):
>>  def __getattr__(self, attr):
>>  raise AttributeError("raised from A.__getattr__ to stop
>> execution")
>>
>> a = A()
>> print(a.x)
>>
>> results in:
>>
>> Traceback (most recent call last):
>>File "test.py", line 6, in 
>>  print(a.x)
>>File "test.py", line 3, in __getattr__
>>  raise AttributeError("raised from A.__getattr__ to stop execution")
>> AttributeError: raised from A.__getattr__ to stop execution
>>
>> The thing to note here is that the AttributeError on the normal
>> __getattribute__'s lookup isn't in the stack trace.  That error is:
>> Traceback (most recent call last):
>>File "test2.py", line 35, in 
>>  print(a.x)
>> AttributeError: 'A' object has no attribute 'x'
>>
>> -- that last line, "AttributeError: 'A' object has no attribute 'x'" does
>> not appear in the stack trace for my above example (because __getattr__ is
>> implemented).  This is because in python's attribute lookup order,
>> __getattr__ is called if an AttributeError is raised, and that raised
>> 

[issue23404] 'make touch' does not work with git clones of the source repository

[STINNER Victor]

STINNER Victor added the comment:

https://github.com/python/cpython/pull/1405#pullrequestreview-35923931

Zachary Ware: "LGTM, but I haven't fully parsed how the old mess worked. We 
should also have CI (either Travis or buildbot) confirming that make 
rebuild-all doesn't leave any checked-in files modified."

Yeah, such CI would be useful.

--

If we go in this direction, maybe we can go further and also run autoconf && 
autoheader?

While fixing bpo-30232, I had to do a second commit 
(9ed34a89532763cf89f5e11fffb91ef7dee29fed) because my first one 
(5facdbb29169c2799c42f887cef4cd9d087b0167) only modified configure.ac. Well, it 
might be a bot on pull requests, but an extra check wouldn't hurt anyway ;-)

A problem with autoconf is that the result depends on the exact autoconf 
version :-/ For example, autoconf 2.69 of my Fedora 25 wants to remove 
runstatedir from configure. I don't know what is runstatedir, so I had to 
revert these autoconf changes on configure before pushing...

haypo@selma$ touch configure.ac && autoconf && git diff

diff --git a/configure b/configure
index a20cf97..a6b13e8 100755
--- a/configure
+++ b/configure
@@ -783,7 +783,6 @@ infodir
 docdir
 oldincludedir
 includedir
-runstatedir
 localstatedir
 sharedstatedir
 sysconfdir
(...)

A solution would be to use a fixed autoconf version and ensure that configure 
is always generated with the same autoconf version. Maybe Gentoo is a good OS 
for such CI such Gentoo provides multiple versions of autotools, whereas other 
Linux distro usually only provide one version of all autotools tools.

--

___
Python tracker 

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

Re: __getattribute__'s error is not available in __getattr__

[Steve D'Aprano]

On Wed, 3 May 2017 10:11 am, Ethan Furman wrote:

> On 05/02/2017 11:16 AM, Jason Maldonis wrote:
> 
>> Here is the simplest example showing what I mean (there are many more
>> complicating variations this, and unfortunately I'm running into some of
>> them):

[...]


I believe this is the wrong list. Wasn't it on python-dev?




-- 
Steve
Emoji: a small, fuzzy, indistinct picture used to replace a clear and
perfectly comprehensible word.

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

[issue29094] Regression in zipfile writing in 2.7.13

[Larry Hastings]

Larry Hastings added the comment:

What's to decide?  If the new behavior is also broken, we should fix it.  I'd 
like a fix in the next 3.5.

--

___
Python tracker 

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

[issue29094] Regression in zipfile writing in 2.7.13

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

Re: tempname.mktemp functionality deprecation

[Cameron Simpson]

On 01May2017 14:31, Tim Chase  wrote:

On 2017-05-01 18:40, Gregory Ewing wrote:

The following function should be immune to race conditions
and doesn't use mktemp. [loop trying names until os.link does not fail die 
to an existing name]


Ah, this is a good alternative and solves the problem at hand.

As a side-note, apparently os.rename() is only atomic on *nix
systems, but not on Windows.  For the time being, I'm okay with that.


Just to your point about my (bogus) suggestion with NamedTemporaryFile, only 
alternative is a temporary directory, then making a file inside that. But 
Gregory Ewing's suggestion is much more direct.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python package to accept payments in Internet

[Steve D'Aprano]

On Wed, 3 May 2017 02:19 am, Victor Porton wrote:

> I have created a full featured package to accept payments in Internet
> (currently supports PayPal).
[...]
> Buy the commercial version and support scientific research and a new
> principle of the Web I am working on.

What licence is your package? Is it under an open source licence, or
commercial closed source, or is there a choice?


> I hope you don't take this message as spam. Is it OK to post updates of
> our software to this mailing list in the future?

Yes, please do!




-- 
Steve
Emoji: a small, fuzzy, indistinct picture used to replace a clear and
perfectly comprehensible word.

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

[issue29094] Regression in zipfile writing in 2.7.13

[Gregory P. Smith]

Gregory P. Smith added the comment:

release managers need to decide.

--
priority: normal -> release blocker

___
Python tracker 

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

[issue29094] Regression in zipfile writing in 2.7.13

[Gregory P. Smith]

Gregory P. Smith added the comment:

re-opening since, though released, this behavior change broke existing code.

--
nosy: +gregory.p.smith
resolution: fixed -> 
stage: resolved -> commit review
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: __getattribute__'s error is not available in __getattr__

[Ethan Furman]

On 05/02/2017 11:16 AM, Jason Maldonis wrote:


Here is the simplest example showing what I mean (there are many more
complicating variations this, and unfortunately I'm running into some of
them):

class A(object):
 def __getattr__(self, attr):
 raise AttributeError("raised from A.__getattr__ to stop execution")

a = A()
print(a.x)

results in:

Traceback (most recent call last):
   File "test.py", line 6, in 
 print(a.x)
   File "test.py", line 3, in __getattr__
 raise AttributeError("raised from A.__getattr__ to stop execution")
AttributeError: raised from A.__getattr__ to stop execution

The thing to note here is that the AttributeError on the normal
__getattribute__'s lookup isn't in the stack trace.  That error is:
Traceback (most recent call last):
   File "test2.py", line 35, in 
 print(a.x)
AttributeError: 'A' object has no attribute 'x'

-- that last line, "AttributeError: 'A' object has no attribute 'x'" does
not appear in the stack trace for my above example (because __getattr__ is
implemented).  This is because in python's attribute lookup order,
__getattr__ is called if an AttributeError is raised, and that raised
AttributeError gets completely discarded.

So basically I want access to the intermediate AttributeError that caused
__getattr__ to be raised in the first place.


Why?  In most cases* you know which object is missing -- it's the `attr` 
parameter above.

*The exception being an AttributeError raised inside a descriptor.

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

[issue30239] test_asyncore: test_handle_expt() fails on macOS Sierra

[STINNER Victor]

STINNER Victor added the comment:

See also issue #30201:
 [3.5] RecvmsgIntoSCMRightsStreamTest fails with "OSError: [Errno 12] Cannot 
allocate memory" on macOS El Capitan.

--

___
Python tracker 

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

[issue30239] test_asyncore: test_handle_expt() fails on macOS Sierra

[STINNER Victor]

New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86-64%20Sierra%203.5/builds/39/steps/test/logs/stdio

==
FAIL: test_handle_expt (test.test_asyncore.TestAPI_UseIPv4Poll)
--
Traceback (most recent call last):
  File 
"/Users/buildbot/buildarea/3.5.billenstein-sierra/build/Lib/test/test_asyncore.py",
 line 671, in test_handle_expt
self.loop_waiting_for_flag(client)
  File 
"/Users/buildbot/buildarea/3.5.billenstein-sierra/build/Lib/test/test_asyncore.py",
 line 511, in loop_waiting_for_flag
self.fail("flag not set")
AssertionError: flag not set

==
FAIL: test_handle_expt (test.test_asyncore.TestAPI_UseIPv6Poll)
--
Traceback (most recent call last):
  File 
"/Users/buildbot/buildarea/3.5.billenstein-sierra/build/Lib/test/test_asyncore.py",
 line 671, in test_handle_expt
self.loop_waiting_for_flag(client)
  File 
"/Users/buildbot/buildarea/3.5.billenstein-sierra/build/Lib/test/test_asyncore.py",
 line 511, in loop_waiting_for_flag
self.fail("flag not set")
AssertionError: flag not set

--
components: Tests, macOS
messages: 292824
nosy: haypo, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: test_asyncore: test_handle_expt() fails on macOS Sierra
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

[issue23404] 'make touch' does not work with git clones of the source repository

[STINNER Victor]

STINNER Victor added the comment:

The issue #23404 has been marked as a duplicate of this bug: "AMD64 FreeBSD 9.x 
3.x" tries to rebuild Include/opcode.h, timestamp issue.

--

___
Python tracker 

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

[issue29967] "AMD64 FreeBSD 9.x 3.x" tries to rebuild Include/opcode.h, timestamp issue

[STINNER Victor]

Changes by STINNER Victor :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> 'make touch' does not work with git clones of the source 
repository

___
Python tracker 

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

[issue23404] 'make touch' does not work with git clones of the source repository

[STINNER Victor]

STINNER Victor added the comment:

I rewrote Python (UNIX/BSD) build system to not rebuild generated files based 
on file modification time: the action is now explicit. This change should not 
only fix buildbots, but also ease cross-compilation, and more generally make 
Python build less painful! No more funny error when the system only provides 
Python 2.6 and so "make touch" doesn't work, whereas "make touch" was the 
obvious workaround to avoid trying to regenerated files.

The change:
https://github.com/python/cpython/pull/1405

My change adds a global "rebuild-all", but this command is made of multiple 
subcommands:

  - rebuild-ast: Include/Python-ast.h and Python/Python-ast.c
  - rebuild-grammar: Include/graminit.h and Python/graminit.c
  - rebuild-importlib: Python/importlib_external.h and Python/importlib.h
  - rebuild-opcode: Include/opcode.h
  - rebuild-opcode-targets: Python/opcode_targets.h
  - rebuild-typeslots: Objects/typeslots.inc

rebuild-all is not needed if you only want to update AST for example: just run 
"make rebuild-ast && make".

--

As you may expect, the change is quite big for a very sensitive part of Python: 
the build system. Do we want to backport such major change?

Another solution for stable branches to to remove the rebuild of generated 
files from configure and Makefile... Just hope that we will not need it 
anymore? Not sure if it's a good idea. I expect fixes in importlib, so 
"rebuild-importlib" will be needed at least.

Even if I don't trust my own work(!), I would suggest to review carefully my 
change, test it on all buildbots, play with it, and then backport it to 2.7, 
3.5 and 3.6.

Note: Windows is not affected by this bug, right?

--

___
Python tracker 

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

[issue23404] 'make touch' does not work with git clones of the source repository

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +1513

___
Python tracker 

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

[issue29505] Submit the re, json, & csv modules to oss-fuzz testing

[Devin Jeanpierre]

Devin Jeanpierre added the comment:

Aha, I found an existing issue!

For adding to oss-fuzz, is there a contact email we can use that is connected 
to a google account? I am tempted to just put gregory.p.smith on there if not. 
:)




I can volunteer to fuzz some interesting subset of the stdlib. The list I've 
come up with (by counting uses in my code) is:

the XML parser (which seems to be written in C)
struct (unpack)
the various builtins that parse strings (like int())
hashlib
binascii
datetime's parsing
json


I'd also suggest the ast module, since people do use ast.literal_eval on 
untrusted strings, but I probably won't do that one myself.



I wrote a fuzz test for json via upstream simplejson, but the bug on github is 
getting stale: https://github.com/simplejson/simplejson/issues/163

Should I add it to CPython instead?



> We should investigate creating fuzz targets for the Python re module (_sre.c) 
> at a minimum.

If we prioritize based on security risk, I'd argue that this is lower priority 
than things like json's speedup extension module, because people should 
generally not pass untrusted strings to the re module: it's very easy to DOS a 
service with regexes unless you're using RE2 or similar -- which is fuzzed.  In 
contrast, json is supposed to accept untrusted input and people do that very 
often.

(OTOH, I would be willing to bet that fuzzing re will yield more bugs than 
fuzzing json.)

--
nosy: +Devin Jeanpierre

___
Python tracker 

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

Re: getting memory usage of varaibles

[Erik]

On 02/05/17 23:28, Larry Martell wrote:

Anyone have any thoughts on how I can monitor the variables' memory
usage as the script runs?


This is application-specific, but sometimes it helps to look at the
objects' types, or even their values.


The types are dict and list, so they are not very useful, nor were the values.


Given your description, I would hazard a guess that you have a circular 
reference somewhere (such that some objects may remain referenced after 
you believe they should have been discarded). You could _probably_ break 
that circle with some carefully placed 'del' statements somewhere - but 
you'd need to analyze your data structures (and closures) first to see 
if that's the case.


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

[issue30106] test_asyncore: test_handle_write() fails in tearDown()

[STINNER Victor]

Changes by STINNER Victor :


--
resolution:  -> fixed
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

[issue30107] python.core file created when running tests on AMD64 FreeBSD CURRENT Non-Debug 3.x buildbot

[STINNER Victor]

STINNER Victor added the comment:

Oh, I forgot that issue. I'm now happy to be able to close it ;-) The bug was 
fixed!

--
resolution:  -> fixed
stage: backport needed -> 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: getting memory usage of varaibles

[Larry Martell]

On Tue, May 2, 2017 at 5:57 PM, Dan Stromberg  wrote:
> On Tue, May 2, 2017 at 12:53 PM, Larry Martell  
> wrote:
>> I have a script that consumes more and more memory as it runs. It has
>> no globals and the large data structures go out of scope often so
>> should be garbage collected. I've looked at the most likely suspects
>> with sys.getsizeof and they are not growing in size. I did this:
>>
>> sum([sys.getsizeof(o) for o in gc.get_objects()])
>>
>> And I can see it getting larger and larger. But I want to see what it
>> is that is causing this. My thought was to put all the objects in a
>> dict with their sizes and compare them as the program runs and report
>> on the one that are growing. But I can't get the name of the object
>> from gc.get_objects only the id.
>>
>> Anyone have any thoughts on how I can monitor the variables' memory
>> usage as the script runs?
>
> This is application-specific, but sometimes it helps to look at the
> objects' types, or even their values.

The types are dict and list, so they are not very useful, nor were the values.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30234] Remove duplicate checks in test_isinstance

[Jim Fasarakis-Hilliard]

Changes by Jim Fasarakis-Hilliard :


--
resolution:  -> fixed
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

[issue30205] socket.getsockname() type mismatch with AF_UNIX on Linux

[Antoine Pitrou]

Antoine Pitrou added the comment:


New changeset 0d9d61828bbd6cbc289489bf1d439fa91eca3743 by Antoine Pitrou in 
branch '3.5':
Backport bpo-30205 to 3.5 (#1404)
https://github.com/python/cpython/commit/0d9d61828bbd6cbc289489bf1d439fa91eca3743


--

___
Python tracker 

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

Re: getting memory usage of varaibles

[breamoreboy]

On Tuesday, May 2, 2017 at 8:54:46 PM UTC+1, larry@gmail.com wrote:
> I have a script that consumes more and more memory as it runs. It has
> no globals and the large data structures go out of scope often so
> should be garbage collected. I've looked at the most likely suspects
> with sys.getsizeof and they are not growing in size. I did this:
> 
> sum([sys.getsizeof(o) for o in gc.get_objects()])
> 
> And I can see it getting larger and larger. But I want to see what it
> is that is causing this. My thought was to put all the objects in a
> dict with their sizes and compare them as the program runs and report
> on the one that are growing. But I can't get the name of the object
> from gc.get_objects only the id.
> 
> Anyone have any thoughts on how I can monitor the variables' memory
> usage as the script runs?

Haven't tried them but how about https://pypi.python.org/pypi/memory_profiler 
or  https://pythonhosted.org/Pympler/muppy.html.

Kindest regards.

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

[issue30205] socket.getsockname() type mismatch with AF_UNIX on Linux

[Antoine Pitrou]

Changes by Antoine Pitrou :


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

[issue30205] socket.getsockname() type mismatch with AF_UNIX on Linux

[Antoine Pitrou]

Antoine Pitrou added the comment:


New changeset 0c2ff0898db2db9cd9c643dfadbff11761bacf5f by Antoine Pitrou in 
branch '3.6':
Backport bpo-30205 to 3.6 (#1403)
https://github.com/python/cpython/commit/0c2ff0898db2db9cd9c643dfadbff11761bacf5f


--

___
Python tracker 

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

[issue30232] configure: support Git worktree

[STINNER Victor]

STINNER Victor added the comment:


New changeset 360fb81367bb409bb7a1d261d88fcf82cee528f0 by Victor Stinner in 
branch '3.5':
[3.5] bpo-30232: Support Git worktree in configure.ac (#1398) (#1401)
https://github.com/python/cpython/commit/360fb81367bb409bb7a1d261d88fcf82cee528f0


--

___
Python tracker 

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

[issue30205] socket.getsockname() type mismatch with AF_UNIX on Linux

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
pull_requests: +1512

___
Python tracker 

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

[issue30232] configure: support Git worktree

[STINNER Victor]

STINNER Victor added the comment:


New changeset df5692549a68741d3d0228f9fef74f349712 by Victor Stinner in 
branch '2.7':
bpo-30232: Support Git worktree in configure.ac (#1402)
https://github.com/python/cpython/commit/df5692549a68741d3d0228f9fef74f349712


--

___
Python tracker 

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

[issue30205] socket.getsockname() type mismatch with AF_UNIX on Linux

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
pull_requests: +1511

___
Python tracker 

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

Re: getting memory usage of varaibles

[Dan Stromberg]

On Tue, May 2, 2017 at 12:53 PM, Larry Martell  wrote:
> I have a script that consumes more and more memory as it runs. It has
> no globals and the large data structures go out of scope often so
> should be garbage collected. I've looked at the most likely suspects
> with sys.getsizeof and they are not growing in size. I did this:
>
> sum([sys.getsizeof(o) for o in gc.get_objects()])
>
> And I can see it getting larger and larger. But I want to see what it
> is that is causing this. My thought was to put all the objects in a
> dict with their sizes and compare them as the program runs and report
> on the one that are growing. But I can't get the name of the object
> from gc.get_objects only the id.
>
> Anyone have any thoughts on how I can monitor the variables' memory
> usage as the script runs?

This is application-specific, but sometimes it helps to look at the
objects' types, or even their values.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30232] configure: support Git worktree

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +1510

___
Python tracker 

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

[issue30232] configure: support Git worktree

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +1509

___
Python tracker 

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

[issue30232] configure: support Git worktree

[STINNER Victor]

STINNER Victor added the comment:


New changeset 4dae0d111dd7bb34ec730eea2327a3219acff211 by Victor Stinner in 
branch '3.6':
[3.6] bpo-30232: Support Git worktree in configure.ac (#1398)
https://github.com/python/cpython/commit/4dae0d111dd7bb34ec730eea2327a3219acff211


--

___
Python tracker 

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

[issue30223] Add Lib/test/__main__.py in 2.7

[STINNER Victor]

STINNER Victor added the comment:


New changeset 8105dd7f75b6aa5f812522d452cd378372752a10 by Victor Stinner in 
branch '2.7':
bpo-30223: Add global in regrtest main_in_temp_cwd (#1399)
https://github.com/python/cpython/commit/8105dd7f75b6aa5f812522d452cd378372752a10


--

___
Python tracker 

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

[issue30233] [3.5] Warning -- locale was modified by test_idle

[Terry J. Reedy]

Terry J. Reedy added the comment:

I see.  That changes the situation a bit.

--

___
Python tracker 

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

[issue30233] [3.5] Warning -- locale was modified by test_idle

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
assignee:  -> haypo
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue30208] Small typos in IDLE doc

[Cheryl Sabella]

Cheryl Sabella added the comment:

Thank you for that information, Mariatta.  I had to read your description
twice to find the 9dc2b38 commit hash.  Once someone learns this, then they
will remember it, but you may want to highlight it on the cherry-pick
readme.  That was very well written and easy to follow, but I don't
remember it specifying the commit hash to use.

Cherry-pick is an awesome tool.  Can't wait to use it again!   :-)

On Mon, May 1, 2017 at 1:25 PM, Mariatta Wijaya 
wrote:

>
> Mariatta Wijaya added the comment:
>
> One PR per branch is correct.
>
> For future reference, preferably the commit hash to be cherry-picked is
> the one that is merged into CPython's master branch. It can be found at the
> original PR where it says  merged commit  into
> python:master. For PR 1353, it is 9dc2b38.
>
> For this issue, it doesn't make much difference since the PR contains only
> one commit. For PRs that contain multiple commits, it makes more sense to
> cherry-pick the squashed commit to master :)
>
> Thanks :)
>
> --
> nosy: +Mariatta
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue30223] Add Lib/test/__main__.py in 2.7

[STINNER Victor]

STINNER Victor added the comment:

> Hum, it seems like test_regrtest is more and more important.

To be fair, I don't think that this particular bug would be catched by the CI 
since the bug is only triggered on a buildbot which installs Python and runs 
tests on the installed test suite.

It should be fixed by https://github.com/python/cpython/pull/1399

--

___
Python tracker 

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

[issue30205] socket.getsockname() type mismatch with AF_UNIX on Linux

[STINNER Victor]

STINNER Victor added the comment:

> I didn't know getsockname() could return None...

Me neither. Maybe it's a bug? makesockaddr() returns None if addrlen equals 0:  
 
 
if (addrlen == 0) { 
  
/* No address -- may be recvfrom() from known socket */ 
  
Py_RETURN_NONE; 
  
}

--

___
Python tracker 

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

[issue30223] Add Lib/test/__main__.py in 2.7

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +1508

___
Python tracker 

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

[issue30205] socket.getsockname() type mismatch with AF_UNIX on Linux

[Antoine Pitrou]

Antoine Pitrou added the comment:

Oh, yuck.

> Maybe restrict the unit test to Linux since the change was specific to Linux?

That sounds reasonable.  I didn't know getsockname() could return None...

--
nosy: +ned.deily, ronaldoussoren

___
Python tracker 

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

[issue30223] Add Lib/test/__main__.py in 2.7

[STINNER Victor]

STINNER Victor added the comment:

Hum, it seems like test_regrtest is more and more important. Yet another 
regression:

http://buildbot.python.org/all/builders/x86%20Gentoo%20Installed%20with%20X%202.7/builds/126/steps/test/logs/stdio

Traceback (most recent call last):
  File 
"/buildbot/buildarea/2.7.ware-gentoo-x86.installed/build/target/lib/python2.7/runpy.py",
 line 174, in _run_module_as_main
"__main__", fname, loader, pkg_name)
  File 
"/buildbot/buildarea/2.7.ware-gentoo-x86.installed/build/target/lib/python2.7/runpy.py",
 line 72, in _run_code
exec code in run_globals
  File 
"/buildbot/buildarea/2.7.ware-gentoo-x86.installed/build/target/lib/python2.7/test/regrtest.py",
 line 1684, in 
main_in_temp_cwd()
  File 
"/buildbot/buildarea/2.7.ware-gentoo-x86.installed/build/target/lib/python2.7/test/regrtest.py",
 line 1664, in main_in_temp_cwd
TESTCWD = os.path.join(TEMPDIR, TESTCWD)
UnboundLocalError: local variable 'TEMPDIR' referenced before assignment

--
resolution: fixed -> 
status: closed -> open

___
Python tracker 

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

[issue30205] socket.getsockname() type mismatch with AF_UNIX on Linux

[STINNER Victor]

STINNER Victor added the comment:

Maybe restrict the unit test to Linux since the change was specific to Linux?

--

___
Python tracker 

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

[issue30205] socket.getsockname() type mismatch with AF_UNIX on Linux

[STINNER Victor]

STINNER Victor added the comment:

Test fails on  x86 Tiger 3.x:

http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/600/steps/test/logs/stdio

==
FAIL: testUnbound (test.test_socket.TestUnixDomain)
--
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_socket.py", 
line 4687, in testUnbound
self.assertEqual(self.sock.getsockname(), '')
AssertionError: None != ''

--
nosy: +haypo

___
Python tracker 

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

[issue27593] Deprecate sys._mercurial and create sys._git

[STINNER Victor]

STINNER Victor added the comment:

> I think that covers it!

Cool, good job ;-)

--

___
Python tracker 

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

[issue30232] configure: support Git worktree

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +1507

___
Python tracker 

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

[issue30233] [3.5] Warning -- locale was modified by test_idle

[STINNER Victor]

STINNER Victor added the comment:

> I intentionally did not patch 3.5 and merge forward because the warning was 
> neither unique nor a failure,

I modified buildbots to log warnings in all branches. I'm now fixing all 
warnings to be able to identify quickly real bugs. The warning is reproduced by 
all 3.5 Windows buildbots.

--

___
Python tracker 

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

[issue30233] [3.5] Warning -- locale was modified by test_idle

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +1506

___
Python tracker 

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

[issue27372] Test_idle should stop changing locale

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +1505

___
Python tracker 

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

[issue29094] Regression in zipfile writing in 2.7.13

[Thomas Wouters]

Thomas Wouters added the comment:

For the record, this new behaviour is wrong. It's not immediately obvious from 
the ZIP spec, but offsets have to be from the start of the file, not the 
archive, or ZIP64 can't work. And yes, that means you can't blindly concatenate 
ZIP files to other files, you have to rewrite them.

The way to create an 'embedded' ZIP archive like requested in issue #26293 is 
to write it to a separate file (or file-like object). Making "a" have this 
magical and wrong-for-almost-anyone meaning is... confusing, to say the least. 
The change certainly doesn't belong in a bugfix release, but I guess it's too 
late for that now. 

It's also not documented; the docs mention this:

  If mode is 'a' and file refers to an existing ZIP file, then
  additional files are added to it. If file does not refer to a ZIP
  file, then a new ZIP archive is appended to the file. This is
  meant for adding a ZIP archive to another file (such as
  python.exe).

which is ambiguous at best and certainly suggests the resulting file would be 
usable as-is, which is not the case if you use mode "a" (but *is* the case if 
you use mode "w", since 342bc734f523).

--
nosy: +twouters

___
Python tracker 

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

[issue30232] configure: support Git worktree

[STINNER Victor]

STINNER Victor added the comment:


New changeset 9ed34a89532763cf89f5e11fffb91ef7dee29fed by Victor Stinner in 
branch 'master':
bpo-30232: Regenerate configure (#1396)
https://github.com/python/cpython/commit/9ed34a89532763cf89f5e11fffb91ef7dee29fed


--

___
Python tracker 

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

Re: Rosetta: Sequence of non-squares

[breamoreboy]

On Tuesday, May 2, 2017 at 12:15:02 PM UTC+1, Tim Golden wrote:
> On 02/05/2017 11:18, Rhodri James wrote:
> > On 02/05/17 08:20, Mark Summerfield via Python-list wrote:
> >>
> >> (The posts are already filtered out of the official comp.lang.python
> >> list, but they can't do this for the Google Groups version.)
> >
> > Careful! The posts are filtered out of the official Python mailing list,
> > but the comp.lang.python newsgroup is unmoderated and cannot do such
> > filtering.
> >
> 
> True -- it's easy to get confused especially since Google Groups (which 
> operates like a combined web forum / mailing list) is gatewayed to the 
> newsgroup while Gmane (which operates like a newsgroup / web archive) is 
> gatewayed to the mailing list!
> 
> TJG

A problem at the moment is that although the gmane side works, you can't get 
onto the website to flag anything that is undesirable, 
http://news.gmane.org/gmane.comp.python.general just gives a "Page Not Found" 
message, nothing else at all :(

Kindest regards.

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

getting memory usage of varaibles

[Larry Martell]

I have a script that consumes more and more memory as it runs. It has
no globals and the large data structures go out of scope often so
should be garbage collected. I've looked at the most likely suspects
with sys.getsizeof and they are not growing in size. I did this:

sum([sys.getsizeof(o) for o in gc.get_objects()])

And I can see it getting larger and larger. But I want to see what it
is that is causing this. My thought was to put all the objects in a
dict with their sizes and compare them as the program runs and report
on the one that are growing. But I can't get the name of the object
from gc.get_objects only the id.

Anyone have any thoughts on how I can monitor the variables' memory
usage as the script runs?
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27593] Deprecate sys._mercurial and create sys._git

[STINNER Victor]

STINNER Victor added the comment:


New changeset fd6c8bb89e834898c26620c9ab9afc6aaecb6b28 by Victor Stinner in 
branch '2.7':
bpo-27593: Revise git SCM build info. (#744) (#746) (#1392)
https://github.com/python/cpython/commit/fd6c8bb89e834898c26620c9ab9afc6aaecb6b28


--

___
Python tracker 

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

[issue30232] configure: support Git worktree

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +1504

___
Python tracker 

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

[issue30232] configure: support Git worktree

[STINNER Victor]

STINNER Victor added the comment:


New changeset 5facdbb29169c2799c42f887cef4cd9d087b0167 by Victor Stinner in 
branch 'master':
bpo-30232: Support Git worktree in configure.ac (#1391)
https://github.com/python/cpython/commit/5facdbb29169c2799c42f887cef4cd9d087b0167


--

___
Python tracker 

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

[issue30238] 2to3 doesn't detect or fix Exception indexing

[Daniel Lenski]

New submission from Daniel Lenski:

Python 2.7 allows indexing an Exception object to access its args list.

>>> e=Exception('foo','bar','baz')
>>> assert e[0] is e.args[0]

This doesn't work in 3.5:

>>> e=Exception('foo','bar','baz')
>>> e.args[0]
'foo'
>>> e[0]
TypeError: 'Exception' object is not subscriptable

This conversion (e[x] -> e.args[x]) seems like it ought to be fairly 
straightforward to support in 2to3.

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 292799
nosy: dlenski
priority: normal
severity: normal
status: open
title: 2to3 doesn't detect or fix Exception indexing
type: enhancement
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

__getattribute__'s error is not available in __getattr__

[Jason Maldonis]

Moving this conversation from python-dev to here because I shouldn't have
sent it to python-dev.

My original message:
I'm working on a large class architecture and I find myself often
overloading __getattr__.  I am continuously running into the issue where I
want __getattr__ to have access to the error that was raised in
__getattribute__, but it seems completely unavailable. Is that true?

What I've learned since then:
There is some weird interplay between __getattribute__, __getattr__, and
python's attribute lookup order which I don't entirely understand.  I've
learned some things from Nick Coghlan and Joao S. O. Bueno, which I'll try
to summarize:

* __getattribute__ does not call __getattr__ within itself; instead,
__getattr__ seems to be called during python's natural attribute lookup
order, but only if an AttributeError is raised during this lookup.
- This has the side effect that calling __getattr__ from __getattribute__
doesn't work properly.

* If __getattr__ is triggered (when an AttributeError is raised during
attribute lookup), it will not have any information about the
AttributeError that triggered it.

* Things may get more complicated if we are doing an attribute lookup on a
property, and an AttributeError is raised within the property's method.
(This is because properties are data descriptors, which complicates
python's natural lookup order.)


Here is the simplest example showing what I mean (there are many more
complicating variations this, and unfortunately I'm running into some of
them):

class A(object):
def __getattr__(self, attr):
raise AttributeError("raised from A.__getattr__ to stop execution")

a = A()
print(a.x)

results in:

Traceback (most recent call last):
  File "test.py", line 6, in 
print(a.x)
  File "test.py", line 3, in __getattr__
raise AttributeError("raised from A.__getattr__ to stop execution")
AttributeError: raised from A.__getattr__ to stop execution

The thing to note here is that the AttributeError on the normal
__getattribute__'s lookup isn't in the stack trace.  That error is:
Traceback (most recent call last):
  File "test2.py", line 35, in 
print(a.x)
AttributeError: 'A' object has no attribute 'x'

-- that last line, "AttributeError: 'A' object has no attribute 'x'" does
not appear in the stack trace for my above example (because __getattr__ is
implemented).  This is because in python's attribute lookup order,
__getattr__ is called if an AttributeError is raised, and that raised
AttributeError gets completely discarded.

So basically I want access to the intermediate AttributeError that caused
__getattr__ to be raised in the first place.


This is complicated, and I may have explained something poorly. If so,
please don't hesitate to ask for more explanation or examples.  This is
already long, so I'll stop typing now.

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

[issue30223] Add Lib/test/__main__.py in 2.7

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thanks Zachary!

--

___
Python tracker 

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

[issue30223] Add Lib/test/__main__.py in 2.7

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset 8e158b2316385497c7b6b818d8b45855d7f87f0b by Serhiy Storchaka in 
branch '2.7':
[2.7] bpo-30223: Fix test_xpickle for Python 2.4. (#1395)
https://github.com/python/cpython/commit/8e158b2316385497c7b6b818d8b45855d7f87f0b


--

___
Python tracker 

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

[issue30223] Add Lib/test/__main__.py in 2.7

[Zachary Ware]

Zachary Ware added the comment:

2.4 is rather far out of date, but PR1395 is simple enough.  I would support 
re-adding test_xpickle in 3.x, and can ensure that every major version is 
available on that buildbot to exercise it.

--

___
Python tracker 

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