[issue11610] Improved support for abstract base classes with descriptors

[Daniel Urban]

Daniel Urban  added the comment:

It doesn't work with staticmethod:

>>> import abc
>>> 
>>> class C(metaclass=abc.ABCMeta):
... @staticmethod
... @abc.abstractmethod
... def foo(x):
... raise NotImplementedError()
... 
>>> class D(C):
... @staticmethod
... def foo(x):
... return x + 1
... 
>>> D()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: Can't instantiate abstract class D with abstract methods foo.__func__
>>>

--

___
Python tracker 

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

[issue11610] Improved support for abstract base classes with descriptors

[Darren Dale]

Darren Dale  added the comment:

On Sat, Jun 11, 2011 at 3:11 AM, Daniel Urban  wrote:
>
> Daniel Urban  added the comment:
>
> It doesn't work with staticmethod:
>
 import abc

 class C(metaclass=abc.ABCMeta):
> ...     @staticmethod
> ...     @abc.abstractmethod
> ...     def foo(x):
> ...             raise NotImplementedError()
> ...
 class D(C):
> ...     @staticmethod
> ...     def foo(x):
> ...             return x + 1
> ...
 D()
> Traceback (most recent call last):
>  File "", line 1, in 
> TypeError: Can't instantiate abstract class D with abstract methods 
> foo.__func__

You still need to use @abc.abstractstaticmethod.

--

___
Python tracker 

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

[issue12310] Segfault in test_multiprocessing

[Charles-François Natali]

Charles-François Natali  added the comment:

I think it might be related to Issue #6721.

Using a mutex/condition variable after fork (from the child process) is unsafe: 
it can lead to deadlocks, and on OS-X, it seems like it can lead to segfaults.

Normally, Queue's synchronization primitives are reinitialized after fork, see 
Queue._after_fork() method.

But here, what happens is the following (well, that's an hypothesis):

Lib/multiprocessing/process.py", line 270 in _bootstrap
:
_current_process = self
util._finalizer_registry.clear()
util._run_after_forkers()

- the old _current_process' reference count drops to zero
- it's deallocated, and since it holds the last reference to a Queue, the queue 
is finalized
- as a consequence, the Queue._finalize_close() callback (registered through a 
Finalize object) is called
- Queue._finalize_close() tries to acquire, signal and release the _notempty 
Condition, but the Condition hasn't been reinitialized yet, because 
util._run_after_forkers() is called 2 lines below
- segfault

It's probably been triggered by Antoine's patches, but I'm pretty sure this bug 
has always been there.

I think that moving util._run_after_forkers() up 2 lines should fix the 
segfaults, but with that change test_number_of_objects fails (I didn't 
investigate why).

--
nosy: +neologix

___
Python tracker 

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

[issue11553] Docs for: import, packages, site.py, .pth files

[Graham Wideman]

Graham Wideman  added the comment:

Hi Eric,  Thanks for starting to review this, and your responses are 
encouraging. Some comments inline below.

FWIW, along the way I accumulated my own notes on this topic, on some pages 
here:

grahamwideman.wikispaces.com
(Left navigation panel...)
Software development > Python > Organization for common modules

Might be of interest as feedback on the digging process I needed in order to 
get some clarity on these issues, and also shows my references.

>> Exactly what variants of arguments are possible, and what are their effects?
>Does http://docs.python.org/dev/library/functions#__import__ help? Does 
>http://docs.python.org/dev/library/importlib ?

Well somewhat overkill -- because the matter of interest was args for from... 
and import, while the docs you mention are for more complicated underlying 
functions. (Interesting nonetheless.)

>> Current docs are unclear on points such as:
>> -- is __init__.py needed on subpackage directories?
>Yes, it always has.  I think there was some discussion about removing them in 
>py3k, but this was rejected.
I came to same conclusion.. but have seen it described otherwise (in at least 
one book), so good to state this explicitly.

>> -- the __all__ variable: Does it act generally to limit visibility of a
>> module or package's attributes, or does pertain only to the
>> 'from...import *' statement?
> Both. 

I'm pretty sure that's not correct -- pretty sure that __all__ only specifies 
what's included in from...import *, and does not prevent access via 
from...import specific_attrib.  But I may have tested incorrectly.

   
>> Seriously misleading discussion of .pth files.  [snip]
>Agreed. 

Cool -- I think it's well worth fixing this area for sure!

>> In addsitepackages(), the library directory for Windows (the else clause)
>> is shown as lower-case 'lib' instead of 'Lib'.
>I don’t see any else clause in the 2.7 or 3.3 code.  Otherwise you’re right.

Sorry, the lowecase 'lib' issue is in 
  getsitepackages()... 
  if sys.platform in(...) ... 
  else:...
sitepackages.append(os.path.join(prefix, "lib", "site-packages"))

>> sys
>> Could helpfully point to a discussion of the typical items to
>> be found in sys.path under normal circumstances
>Hm, this would be very platform-specific.  What use cases would that help?

It would demystify how python already knows how to find various things under 
vanilla circumstances.

>> 'Installing Python Modules' document
>> "Windows has no concept of a user’s home directory, " and so on.
>The author probably meant that there was no $HOME environment variable, ~ 
>shortcut and all that.

Fair enough, but in actuality there *is* a user-specific location (on Windows) 
examined by site.py, which is in %APPDATA%\Python\.

>> For Windows suggests 'prefix' (default: C:\Python) as an installation 
>> directory.
>> This is indeed one of the possible 'site-package' directories, but surely it 
>> is
>> deprecated in favor of C:\Python\Lib\site-packages, which this section does 
>> not mention.
>Don’t confuse the prefix and the install dir.  The directory for Python 
>modules is computed as prefix + Lib/site-packages.

Currently, under "Alternate installation: Windows (the prefix scheme)", it says:
python setup.py install --prefix="\Temp\Python"
to install modules to the \Temp\Python directory on the current drive.
Does this really mean "install modules to \Temp\Python\Lib\site-packages"?
(And as a side point, surely installing under the Temp directory is a strange 
location to pick for an example?)

>That was my initial feeback; I think I’ve covered all of your points. 
Looking forward!

--

___
Python tracker 

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

[issue11610] Improved support for abstract base classes with descriptors

[Darren Dale]

Darren Dale  added the comment:

[...]
>> Traceback (most recent call last):
>>  File "", line 1, in 
>> TypeError: Can't instantiate abstract class D with abstract methods 
>> foo.__func__
>
> You still need to use @abc.abstractstaticmethod.

Thinking about this some more, I think the error you found should be
considered a problem. The issue is with the descriptor access itself:
In class C we inspect the staticmethod instance in the namespace dict
passed to ABCMeta and find foo's abstract __func__. But later, ABCMeta
identifies C as a base of D, identifies C.foo.__func__ from
C.__abstractmethods__, then does a getattr on the formative D class.
D.__dict__['foo'] is a descriptor, which when accessed as D.foo
returns D.__dict__['foo'].__func__ (as opposed to the other
descriptors we have been discussing, where descriptor "get" access is
only invoked by an instance of the class). ABCMeta needs to inspect
the descriptor itself, not whatever the descriptor wants to return
when accessed. We can't use D.__dict__ to access the foo descriptor,
since some other base class of D may have provided the concrete
implementation of foo. Does anyone know another way to search the MRO
and return the foo descriptor?

You helped bring up another point: all functions are descriptors,
since they all have __get__ methods. That means every method is going
to be inspected for abstract members. Is this a problem?

--

___
Python tracker 

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

[issue11553] Docs for: import, packages, site.py, .pth files

[Nick Coghlan]

Nick Coghlan  added the comment:

Thanks for getting started with such a detailed review on this Graham. We've 
known the documentation in this area has been flawed for a long time, but 
actually *fixing* seemed like such a big task that it has tended to get pushed 
to the bottom of our respective to-do lists.

And so as things have been tweaked, the already flawed documentation has fallen 
even further out of date (as it wasn't always clear where updates should be 
included).

Simply breaking it down into a smaller list of easier to tackle problems is a 
big step towards getting something done about it.

A couple of specific notes:

__all__ only affects import *, and may also affect documentation tools (e.g. 
pydoc will respect __all__ when deciding what to display). It has no effect on 
attribute retrieval from modules.

pkgutil.extend_path() is used to modify pkg.__path__ attributes, *not* 
sys.path. It is used to allow a single package to span multiple directories, 
forming the basis for "namespace packages" (see 
http://www.python.org/dev/peps/pep-0382/#namespace-packages-today). 

Packages are technically a kind of module, but we're somewhat inconsistent in 
our use of the term "module". Sometimes it means all kinds of modules (frozen, 
builtin, extension, package, compiled, source), sometimes it means 
anything-but-a-package and occasionally it specifically means pure Python 
modules. In theory, context should make it clear which interpretation is 
intended. In practice, the boundaries between the first two meanings get a 
little blurry.

--

___
Python tracker 

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

[issue11610] Improved support for abstract base classes with descriptors

[Nick Coghlan]

Nick Coghlan  added the comment:

inspect.getattr_static has the necessary logic to search for descriptors 
without invoking them.

However, it may be better to revert to the idea of pushing this functionality 
back onto the individual descriptors and have the problematic descriptors like 
property and staticmethod simply implement __isabstractmethod__ as a property.

property:
  @property
  def __isabstractmethod__(self):
return (self.fget.__isabstractmethod__ or
self.fset.__isabstractmethod__ or
self.fdel.__isabstractmethod__)

staticmethod/classmethod:

  @property
  def __isabstractmethod__(self):
return self.__func__.__isabstractmethod__

With this approach, the "one true way" to handle abstract descriptors would be 
to do:

  #instance method
  @abstractmethod
  def f(self):
...

  @property
  @abstractmethod
  def f(self):
...

  @classmethod
  @abstractmethod
  def f(self):
...

  @staticmethod
  @abstractmethod
  def f(self):
...

This wouldn't allow for the prettier error messages, but it's much cleaner than 
having ABCMeta trawling through class attribute dir() lists.

--
nosy: +michael.foord

___
Python tracker 

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

[issue11610] Improved support for abstract base classes with descriptors

[Darren Dale]

Darren Dale  added the comment:

On Sat, Jun 11, 2011 at 8:55 AM, Nick Coghlan  wrote:
>
> Nick Coghlan  added the comment:
>
> inspect.getattr_static has the necessary logic to search for descriptors 
> without invoking them.

Unfortunately, we can't import inspect, even inside ABCMeta.__new__.

> However, it may be better to revert to the idea of pushing this functionality 
> back onto the individual descriptors and have the problematic descriptors 
> like property and staticmethod simply implement __isabstractmethod__ as a 
> property.
>
> property:
>  @property
>  def __isabstractmethod__(self):
>    return (self.fget.__isabstractmethod__ or
>            self.fset.__isabstractmethod__ or
>            self.fdel.__isabstractmethod__)
>
> staticmethod/classmethod:
>
>  @property
>  def __isabstractmethod__(self):
>    return self.__func__.__isabstractmethod__

That's a good idea.

> With this approach, the "one true way" to handle abstract descriptors would 
> be to do:
>
>  #instance method
>  @abstractmethod
>  def f(self):
>    ...
>
>  @property
>  @abstractmethod
>  def f(self):
>    ...
>
>  @classmethod
>  @abstractmethod
>  def f(self):
>    ...
>
>  @staticmethod
>  @abstractmethod
>  def f(self):
>    ...
>
> This wouldn't allow for the prettier error messages, but it's much cleaner 
> than having ABCMeta trawling through class attribute dir() lists.

Those classes could conceivably do:

@property
def __abstractmethods__(self):
return ("...", ...)

It would not be required, but if ABCMeta found it, it could use it.
Just a thought.

Darren

--

___
Python tracker 

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

[issue11553] Docs for: import, packages, site.py, .pth files

[Greg Słodkowicz]

Changes by Greg Słodkowicz :


--
nosy: +Greg.Slodkowicz

___
Python tracker 

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

[issue12291] file written using marshal in 3.2 can be read by 2.7, but not 3.2 or 3.3

[Vinay Sajip]

Vinay Sajip  added the comment:

Patch is now in my public sandbox on hg.python.org.

--
hgrepos: +26

___
Python tracker 

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

[issue11553] Docs for: import, packages, site.py, .pth files

[Graham Wideman]

Graham Wideman  added the comment:

Hi Nick: Thanks for your additional points. Comments inline:

> __all__ only affects import *, and may also affect documentation tools (e.g. 
> pydoc will respect __all__ when deciding what to display). It has no effect 
> on attribute retrieval from modules.

That's indeed my understanding. So the doc (6. Simple statements) which says 
that __all__ determines the list of "public names" is a bit of a red herring.  
Attributes are accessible (ie: public) regardless of whether on the __all__ 
list.  Instead the __all__ list establishes the list of names imported by *, 
and makes those names reference-able without a module prefix. (Plus gives hints 
about intent to doc tools.)

> pkgutil.extend_path() is used to modify pkg.__path__ attributes, *not* 
> sys.path. 

Understood, and perhaps my point was obtuse.  I was pointing out that the doc 
for extend_path discusses .pkg entries which point to package dirs, and that 
this, it says, is like .pth files. I claim that an entry in a .pth files should 
NOT point to a package dir, but rather to one level up: to a dir that 
*contains* package dirs. (Pointing a .pth entry directly at a package dir will 
break package behavior by exposing the constituent modules to sys.path.)  Hence 
the doc for extend_path is misleadingly suggesting a wrong idea about .pth 
files.

--

___
Python tracker 

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

[issue12291] file written using marshal in 3.2 can be read by 2.7, but not 3.2 or 3.3

[Vinay Sajip]

Vinay Sajip  added the comment:

For some reason, "Create Patch" is failing with a

[Errno 2] No such file or directory: 
'/home/roundup/trackers/tracker/cpython/Doc/Makefile'

I've logged an issue on the meta tracker:

http://psf.upfronthosting.co.za/roundup/meta/issue405

--

___
Python tracker 

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

[issue12310] Segfault in test_multiprocessing

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Less disruptive approach:

old_process = _current_process
_current_process = self
try:
util._finalizer_registry.clear()
util._run_after_forkers()
finally:
del old_process

This will delay finalization of the old process object until after 
_run_after_forkers() is executed, without (hopefully) messing with semantics.

--

___
Python tracker 

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

[issue10115] Support accept4() for atomic setting of flags at socket creation

[Charles-François Natali]

Charles-François Natali  added the comment:

No one seems to object, and since this approach has been suggested by
Martin and  is consistent with the posix module's policy (i.e. a thin
wrapper around the underlying syscall), I guess you can go ahead.

--

___
Python tracker 

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

[issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE

[Charles-François Natali]

Charles-François Natali  added the comment:

For oss_check_closed.diff, should I apply it to default only or to every branch?

--

___
Python tracker 

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

[issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> For oss_check_closed.diff, should I apply it to default only or to
> every branch?

Only default I'd say.

--

___
Python tracker 

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

[issue10897] UNIX mmap unnecessarily dup() file descriptor

[Charles-François Natali]

Charles-François Natali  added the comment:

> Perhaps by adding some new argument to the mmap constructor? (dup_fd = True)

I don't really like the idea of exposing the FD duplication to the
user, because:
- it's an implementation detail
- it doesn't reflect any argument of the POSIX mmap version
- it should False by default

I really think that application code expecting to be able to resize
the mmap after closing the FD is broken, but I'm also a really strong
advocate of backward compatibility...
I don't see any satisfying solution.

--

___
Python tracker 

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

[issue12315] Improve http.client.HTTPResponse.read documentation

[Antoine Pitrou]

Changes by Antoine Pitrou :


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

___
Python tracker 

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

[issue12310] Segfault in test_multiprocessing

[Charles-François Natali]

Charles-François Natali  added the comment:

Yes, I also tried this.
This fixed the test_multiprocessing failure, but I think it triggered a failure 
in test_concurrent_futures (didin't look in more detail).
Would it be possible to try this on the buildbot to see if it fixes the 
segfaults?

--

___
Python tracker 

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

[issue11610] Improved support for abstract base classes with descriptors

[Darren Dale]

Darren Dale  added the comment:

[...]
>
> This wouldn't allow for the prettier error messages, but it's much cleaner 
> than having ABCMeta trawling through class attribute dir() lists.

I think there is another reason to do it this way. Suppose I have a
custom descriptor MyProperty that stores its getter as
MyProperty.my_fget. In this example:

class C:
@property
@abstractmethod
def foo(self): return 1

class D:
@MyProperty
def foo(self): return 2

if ABCMeta determines C.foo.fget is abstract, it will not recognize
that D.foo.my_fget supplies the concrete implementation. MyProperty
may provide the same interface as property, it may even subclass
property, but there is no guarantee its implementation conforms to
property the way ABCMeta is expecting it to.

The downside to making __isabstractmethod__ a property is that if C
declares foo to be a read/write property, and D redefines foo as
read-only and concrete, ABCMeta will not recognize the oversight. That
seems a significant deficiency to me. I'm not sure how to proceed.

Darren

--

___
Python tracker 

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

[issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE

[Roundup Robot]

Roundup Robot  added the comment:

New changeset d0952a2fb7bd by Charles-François Natali in branch 'default':
Issue #12287: In ossaudiodev, check that the device isn't closed in several
http://hg.python.org/cpython/rev/d0952a2fb7bd

--
nosy: +python-dev

___
Python tracker 

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

[issue9098] MSYS build fails with `S_IXGRP' undeclared

[Yuri]

Yuri  added the comment:

I fixed all build problems on the current MinGW32. python.exe builds ok, but 
build fails since python.exe can't find some modules after this. Not sure why.

--
keywords: +patch
nosy: +yurivict
Added file: http://bugs.python.org/file22329/python-3.2.patch

___
Python tracker 

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

[issue11595] Miscellaneous bugs in cfg_to_args() utility function

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 303e3693d634 by Éric Araujo in branch 'default':
Move useful function to packaging.util.
http://hg.python.org/cpython/rev/303e3693d634

New changeset 06670bd0e59e by Éric Araujo in branch 'default':
Fix assorted bugs in packaging.util.cfg_to_args (#11595).
http://hg.python.org/cpython/rev/06670bd0e59e

--
nosy: +python-dev

___
Python tracker 

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

[issue11599] Useless error message when distutils fails compiling

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 3ba34c03f2fc by Éric Araujo in branch 'default':
Adjust logging in packaging.util.spawn (related to #11599)
http://hg.python.org/cpython/rev/3ba34c03f2fc

--
nosy: +python-dev

___
Python tracker 

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

[issue12240] Allow multiple setup_hooks

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 5f0cd4844061 by Éric Araujo in branch 'default':
Allow multiple setup hooks in packaging’s setup.cfg files (#12240).
http://hg.python.org/cpython/rev/5f0cd4844061

--
nosy: +python-dev

___
Python tracker 

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

[issue12313] make install misses packaging module

[Éric Araujo]

Éric Araujo  added the comment:

> Also you may want to add some of the packaging test directories to
> those excluded in the calls to compileall.py a little further down in
> the libinstall target.

Ah, good one.  I guess doing this could have prevented 
http://hg.python.org/cpython/rev/9041520be581

--

___
Python tracker 

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

[issue828450] sdist generates bad MANIFEST on Windows

[Éric Araujo]

Éric Araujo  added the comment:

> I just recreated this patch against version 2.7, so I'm not sure it
> can be applied to all the listed versions.
It’s okay, distutils in 2.7 and 3.x is very similar, I can port.

> Note: there still are two pathes, one for sdist.py and another for
> test_sdist.py
Why?  hg diff can create one patch for many files.  It’s a bit easier if you 
upload just one patch.  Anyway, it’s not an issue, just upload the missing 
patch for sdist.py.

--

___
Python tracker 

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

[issue11595] Miscellaneous bugs in cfg_to_args() utility function

[Éric Araujo]

Éric Araujo  added the comment:

Thanks again!

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue11599] Useless error message when distutils fails compiling

[Éric Araujo]

Éric Araujo  added the comment:

I intend to ask on distutils-sig whether doing the change in distutils would 
break code.

--
assignee: tarek -> eric.araujo

___
Python tracker 

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

[issue12279] Add build_distinfo command to packaging

[Éric Araujo]

Éric Araujo  added the comment:

I forgot one thing: setuptools’ egg_info command does write a list of paths, so 
we can look at how it solved the problem with the RECORD and RESOURCES files.

Higery: Michael is willing to work with you on this bug.

--

___
Python tracker 

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

[issue12240] Allow multiple setup_hooks

[Éric Araujo]

Éric Araujo  added the comment:

Done.

--
assignee: tarek -> eric.araujo
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express

[Éric Araujo]

Éric Araujo  added the comment:

> Hmm, in http://bugs.python.org/issue7511#msg106420 Tarek appeared to
> be supportive of the patch.

I believe Martin has more knowledge about Windows.

--

___
Python tracker 

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

[issue12317] inspect.getabsfile() is not documented

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
assignee: giampaolo.rodola
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: inspect.getabsfile() is not documented
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

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

[issue12169] Factor out common code for d2 commands register, upload and upload_docs

[John Edmonds]

John Edmonds  added the comment:

Here is the patch, re-written for the packaging module.

--
Added file: http://bugs.python.org/file22330/patch.diff

___
Python tracker 

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

[issue9284] inspect.findsource() cannot find source for doctest code

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 527c40add91d by Benjamin Peterson in branch '2.7':
allow "fake" filenames in findsource (closes #9284)
http://hg.python.org/cpython/rev/527c40add91d

New changeset 6cc4579dca02 by Benjamin Peterson in branch '3.2':
allow "fake" filenames in findsource (closes #9284)
http://hg.python.org/cpython/rev/6cc4579dca02

New changeset f05affb0bb2a by Benjamin Peterson in branch 'default':
merge 3.2 (#9284)
http://hg.python.org/cpython/rev/f05affb0bb2a

--
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue12206] Documentation Std. Library 15.7.5 "LogRecord objects": Parameters: level(currently wrong) -> levelno (correct)

[Vinay Sajip]

Vinay Sajip  added the comment:

Attached is a simple patch clarifying that the level argument in the 
constructor maps to the two LogRecord attributes, levelno and levelname,

--
keywords: +patch
Added file: http://bugs.python.org/file22331/patch12206.diff

___
Python tracker 

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

[issue12318] list + tuple inconsistency

[Filip Gruszczyński]

New submission from Filip Gruszczyński :

You can do this:
>>> [1] + (1,)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: can only concatenate list (not "tuple") to list

But you can do this:

>>> result = [1]
>>> result += (1,)
>>> result
[1, 1]


Is it the expected behaviour, that += does implicit coercion?

--
messages: 138185
nosy: gruszczy
priority: normal
severity: normal
status: open
title: list + tuple inconsistency
versions: Python 3.2

___
Python tracker 

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

[issue12318] list + tuple inconsistency

[Filip Gruszczyński]

Filip Gruszczyński  added the comment:

Obviously first sentence should be "You can't do this:".

--

___
Python tracker 

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

[issue12206] Documentation Std. Library 15.7.5 "LogRecord objects": Parameters: level(currently wrong) -> levelno (correct)

[Roundup Robot]

Roundup Robot  added the comment:

New changeset bb6fe43191c0 by Vinay Sajip in branch '3.2':
Issue #12206: documentation for LogRecord constructor updated re. the level 
argument.
http://hg.python.org/cpython/rev/bb6fe43191c0

New changeset 596adf14914c by Vinay Sajip in branch 'default':
Merged documentation update for issue #12206.
http://hg.python.org/cpython/rev/596adf14914c

--
nosy: +python-dev

___
Python tracker 

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

[issue12206] Documentation Std. Library 15.7.5 "LogRecord objects": Parameters: level(currently wrong) -> levelno (correct)

[Vinay Sajip]

Changes by Vinay Sajip :


--
assignee: docs@python -> vinay.sajip

___
Python tracker 

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

[issue12318] list + tuple inconsistency

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Yes, this is the expected behavior and yes, it is inconsistent.

It's been that way for a long while and Guido said he wouldn't do it again 
(it's in his list of regrets).  However, we're not going to break code by 
changing it (list.__iadd__ working like list.extend).

--
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

___
Python tracker 

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

[issue11610] Improved support for abstract base classes with descriptors

[Eric Snow]

Eric Snow  added the comment:

Perhaps rather than changing ABCMeta, provide a base descriptor class that has 
__isabstractmethod__ implemented to calculate the abstractness.  Then property 
could use that, as could any of the other relevant descriptors we have around.  
The __isabstractmethod__ attribute of the descriptor would itself need to be a 
data-descriptor (which property() is).  That would ensure that 
__isabstractmethod__ is not set directly on the descriptor instance.

I agree with Nick that it may be better to have the descriptor classes take 
care of managing __isabstractmethod__ themselves, instead of having ABCMeta 
compute it.  Special-casing ABCMeta to handle custom __isabstractmethod__ 
calculation for any specific type seems like something we should avoid.

Per your last message, if a specific descriptor has an abstract setter then the 
descriptor should be considered abstract.  If the implementation of that 
attribute is not a descriptor should it raise a TypeError?  If it is a 
descriptor but it does not have a setter, should it likewise fail?  I'm not so 
sure.  We already don't enforce types on abstract attributes.  You don't have 
to implement an abstractproperty with a property, an abstractstaticmethod with 
a staticmethod, nor an abstractclassmethod with a classmethod.  For that matter 
you don't have to implement an abstractmethod with a function.  It just has to 
be an object bound to the same name.  Should descriptors get special treatment 
over any other type that implements __isabstractmethod__?

That brings up a concern of mine.  I've found the name abstractmethod 
(specifically the "method" part) to be misleading.  Any attribute can be 
"abstract" and ABCMeta only cares about __isabstractmethod__.  Maybe having 
"method" in the name is meant to imply the expected use case?  I would rather 
they were called  __isabstractattribute__, and __abstractattributes__, which 
would be less confusing when using ABCs, particularly at first.  Having 
"attribute" in the name is nice, since it makes it clear we're talking about 
attributes, rather than other abstraction contexts.  Having a specific 
abstractmethod decorator is still good since we only decorate functions in an 
ABC.

I'm +1 for deprecating abstractproperty and really all the decorators except 
abstractmethod (if the use cases were addressed).  If abstractmethod were smart 
about on which object it sets __isabstractmethod__, the other decorators would 
be unnecessary;  and the order in which you decorate would not matter as much.  
The other decorators could become simple wrappers around abstractmethod if we 
felt the need to keep them around.  It's nice that the decorators say with what 
you are expecting to replace them, but you can get that by using the 
corresponding normal decorators.

--
nosy: +ericsnow

___
Python tracker 

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

[issue12310] Segfault in test_multiprocessing

[STINNER Victor]

STINNER Victor  added the comment:

> Would it be possible to try this on the buildbot to see if it fixes
> the segfaults?

You can fork cpython, modify the code, and run a custom buildbot on your
clone.

--

___
Python tracker 

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

[issue11553] Docs for: import, packages, site.py, .pth files

[Nick Coghlan]

Nick Coghlan  added the comment:

"Public name" is a term that describes a convention, not anything enforced by 
the interpreter. Names starting with underscores typically aren't public either 
(unless documented otherwise), but that has no effect on the ability to 
retrieve them as attributes. A glossary entry defining the term may be 
worthwhile (perhaps with a reference to pydoc.visiblename())

Dirs mentioned in .pkg files *should* be added to "the path". It's just that 
the path in question is pkg.__path__, not sys.path. That could probably be made 
clearer, but the docs aren't wrong as they stand.

--

___
Python tracker 

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

[issue11610] Improved support for abstract base classes with descriptors

[Nick Coghlan]

Nick Coghlan  added the comment:

Remember the goal here is *not* to completely eliminate the need to test that 
objects implement an ABC correctly. It's to make it easier to declare the 
expected interface in a way that helps readers of the ABC definition to figure 
out what is going on, and to reduce the proliferation of abstract descriptors.

Since we made a deliberate choice not to do signature checks when ABCs were 
added to the language, there's nothing an ABC can do to stop someone (for 
example) overriding an abstract method or descriptor "foo" with "foo = 1". 
That's almost certainly wrong, but it's wrong at a level that ABCs don't care 
about.

If someone incorrectly overrides a read/write property with a read-only 
property and there's nothing in their test suite that picks that up, then 
that's a flaw in the test suite, not a flaw in the ABC itself.

Regarding the naming, @abstractmethod and __isabstractmethod__ are definitely 
about methods, or method-based descriptors (such as property). There *could* be 
a case to be made to allow for abstract data attributes, but really, using an 
abstract property should cover that use case well enough.

--

___
Python tracker 

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

[issue12239] msilib VT_EMPTY SummaryInformation properties raise an error (suggest returning None)

[Mark Mc Mahon]

Changes by Mark Mc Mahon :


--
keywords: +patch
Added file: 
http://bugs.python.org/file22332/support_vt_empty_in_summary_getproperty.patch

___
Python tracker 

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

[issue11553] Docs for: import, packages, site.py, .pth files

[Graham Wideman]

Graham Wideman  added the comment:

> "Public name" is a term that describes a convention, not anything enforced by 
> the interpreter. 

And I guess that's really the main point. In other languages Public means 
accessible, and Private means not so.  In Python, Public means "suggested for 
outside consumption", and Private means not so intended, but nonetheless 
accessible. If that was reiterated near the discussion of __all__ it would be 
most helpful.  

>  Dirs mentioned in .pkg files *should* be added to the [...] pkg.__path__, 
> not sys.path. 
> That could probably be made clearer, but the docs aren't wrong as they stand.

Again I've not managed to draw attention to the exact point of contention. 
1. A dir added to a .pkg file evidently should be an actual package dir.  
2. A dir added to a .pth file should NOT be an actual package dir. It should be 
the dir at the level above.

Thus the entries in .pkg and .pth files point to different kinds of things, yet 
the doc I pointed to asserts they are the same in this regard.

--

___
Python tracker 

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

[issue828450] sdist generates bad MANIFEST on Windows

[higery]

higery  added the comment:

OK. I recreated a full version patch. I'll remove old patches.

--
Added file: 
http://bugs.python.org/file22333/change_path_separator_fullversion.patch

___
Python tracker 

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

[issue828450] sdist generates bad MANIFEST on Windows

[higery]

Changes by higery :


Removed file: 
http://bugs.python.org/file21713/change_path_separator_in_MANIFEST.patch

___
Python tracker 

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

[issue828450] sdist generates bad MANIFEST on Windows

[higery]

Changes by higery :


Removed file: http://bugs.python.org/file22328/test_manifest_reading_sdist.diff

___
Python tracker 

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

[issue11610] Improved support for abstract base classes with descriptors

[Eric Snow]

Eric Snow  added the comment:

Didn't mean to sidetrack.  :)  I really appreciate the effort Darren has put 
into this.

--

___
Python tracker 

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

[issue12279] Add build_distinfo command to packaging

[higery]

higery  added the comment:

> Higery: Michael is willing to work with you on this bug.
>

OK.  :)

--
Added file: http://bugs.python.org/file22334/unnamed

___
Python tracker 

___
Higery: Michael is willing to work with you on this 
bug.OK.  :)
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12279] Add build_distinfo command to packaging

[higery]

Changes by higery :


Removed file: http://bugs.python.org/file22334/unnamed

___
Python tracker 

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

[issue9035] os.path.ismount on windows doesn't support windows mount points

[Mark Mc Mahon]

Mark Mc Mahon  added the comment:

I was looking at this - and see that (at least as far as GetFileAttributes is 
concerned) that a mount and a linked directory are seen the same...

Here are some tests using ctypes

# mounted drive
>>> hex(windll.kernel32.GetFileAttributesW(ur"c:\temp\test_c_mount"))
'0x410'

# normal directory
>>> hex(windll.kernel32.GetFileAttributesW(ur"c:\temp\orig"))
'0x10'

# link (created via mklink /d c:\temp\orig c:\temp\here2
>>> hex(windll.kernel32.GetFileAttributesW(ur"c:\temp\here2"))
'0x410'

On futher searching - I found the following link:
http://msdn.microsoft.com/en-us/library/aa363940%28v=vs.85%29.aspx

So the function ismount will need to do the following
a) Get the file attributes
b) check that it's a directory and is a reparse point
c) Use FindFirstFile (and FindNextFile? - I need to test more) to fill in 
WIN32_FIND_DATA.dwResearved0
d) Check that against IO_REPARSE_TAG_MOUNT_POINT (0xA003)

--

___
Python tracker 

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

[issue9035] os.path.ismount on windows doesn't support windows mount points

[Brian Curtin]

Changes by Brian Curtin :


--
nosy: +brian.curtin

___
Python tracker 

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