[issue12522] Implement `os.startfile` under Linux and Mac

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

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

[issue12531] documentation index entries for * and **

[Eli Bendersky]

Changes by Eli Bendersky :


--
nosy: +eli.bendersky

___
Python tracker 

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

[issue12434] Strengthen 2.7 io types warning

[Eli Bendersky]

Eli Bendersky  added the comment:

In my opinion, it's the error messages and docstrings that should be changed, 
not the documentation. This module was introduced in 2.6 and moves on to 2.7, 
and there's no reason to have it throw confusing errors for the sake of easier 
back-patching from 3.x

However, when I run this example on 2.6, I get:

   TypeError: can't write str to text stream

Which (arguably) makes sense, since the docs explicitly say that "Text I/O 
classes work with unicode data."

--
nosy: +eli.bendersky

___
Python tracker 

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

[issue4376] Nested ctypes 'BigEndianStructure' fails

[Vlad Riscutia]

Vlad Riscutia  added the comment:

Also added diff for fix:

- Implemented proposed issubclass(typ, Structure) solution
- Refactored _other_endian function because we used to getattr, catch 
exception, then check if type is array/structure. I believe exception throwing 
should not be on normal code path so I replaced try-except with a check for 
hasattr
- Removed a unittest which becomes deprecated with this fix (unittest asserts 
getting _other_endian for nested struct raises exception which is no longer the 
case)

--
Added file: http://bugs.python.org/file22627/issue4376_fix.diff

___
Python tracker 

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

[issue12434] Strengthen 2.7 io types warning

[Terry J. Reedy]

Terry J. Reedy  added the comment:

My original suggestion is a minimal change suggestion. I do not have much 
opinion on what the maximum change 'should' be.

It would obviously be nice from a user viewpoint if the error message were 
backported to say "unicode argument expected, got 'str'". Then the note change 
might not be needed. But I do not know if the particular message is an accident 
or part of a policy of not fully backporting the code (to aid future 
patching?), or whether there are other messages that would need the same 
treatment.

The module docstring shown by help(io) does not have the terminology note to be 
augmented.

--

___
Python tracker 

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

[issue12485] textwrap.wrap: new argument for more pleasing output

[Tyler Romeo]

Changes by Tyler Romeo :


Removed file: 
http://bugs.python.org/file22573/textwrap.py-new-algorithm-2011-07-04_22-45-53_r71219+.diff

___
Python tracker 

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

[issue12485] textwrap.wrap: new argument for more pleasing output

[Tyler Romeo]

Tyler Romeo  added the comment:

OK, sorry to get back so late, but here's the updated patch without xrange. I 
saw the version change but forgot that I used xrange in the function (old 
habits I guess).

--
Added file: 
http://bugs.python.org/file22626/textwrap.py-beautiful-2011-07-11_22-01-31_r71296+.diff

___
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

[Carl Meyer]

Carl Meyer  added the comment:

You guys are more familiar with the codebase than I am, but it seems to me that 
the RECORD file should clearly either be not present or empty when metadata has 
been built but not yet installed. I don't really think the "invalid PEP 376" 
issue is a problem: PEP 376 describes the metadata for installed distributions; 
it has nothing to say about built metadata for a distribution which has not yet 
been installed.

For purposes of the develop command, if a pth file is used to implement 
develop, then ideally when develop is run a RECORD file would be added 
containing only the path to that pth file, as thats the only file that has 
actually been installed (and the only one that should be removed if the 
develop-installed package is uninstalled).

--
nosy: +carljm

___
Python tracker 

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

[issue12344] Add **kwargs to get_reinitialized_command

[Thomas Holmes]

Changes by Thomas Holmes :


Added file: http://bugs.python.org/file22625/115c0c10b3ba.diff

___
Python tracker 

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

[issue12344] Add **kwargs to get_reinitialized_command

[Thomas Holmes]

Changes by Thomas Holmes :


Removed file: http://bugs.python.org/file22624/7c61eba07f3f.diff

___
Python tracker 

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

[issue12344] Add **kwargs to get_reinitialized_command

[Thomas Holmes]

Changes by Thomas Holmes :


Added file: http://bugs.python.org/file22624/7c61eba07f3f.diff

___
Python tracker 

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

[issue12344] Add **kwargs to get_reinitialized_command

[Thomas Holmes]

Thomas Holmes  added the comment:

I have added a test and made some additional modifications. I had to modify the 
very simple MyCmd object in test_command_cmd.py so that it would have some user 
options with default values and support finalization.

--

___
Python tracker 

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

[issue4376] Nested ctypes 'BigEndianStructure' fails

[Vlad Riscutia]

Vlad Riscutia  added the comment:

Added unit test to reproduce the issue (covers both big endian and little 
endian structures so _other_endian function is hit on any machine).

Test currently fails without fix and passes with proposed fix in place.

--
keywords: +patch
nosy: +vladris
Added file: http://bugs.python.org/file22623/issue4376_test.diff

___
Python tracker 

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

[issue8668] Packaging: add a 'develop' command

[Michael Mulich]

Michael Mulich  added the comment:

On Mon, Jul 11, 2011 at 1:14 PM, Carl Meyer  wrote:
>> * Cases 2, 3, 5 and 6 are strongly related.
> I don't know. I don't consider case 3 useful, because I don't consider
> "I don't want to use a virtualenv" (without some clearer technical
> justification) to be a prejudice the develop feature needs to support;
> especially if supporting it essentially means re-implementing a
> less-capable version of virtualenv within the develop command.

I think your later comments about the use of .pth files solves the
issue for all four cases. We simply make reference in a .pth file in
one of the approved site locations. For example, in case two we would
write a .pth entry to site.USER_SITE. Sound about right?

>> -- Case 5
> Several of these stories make the assumption that even the "in-place"
> installation will require placing a file in the installation location (a
> .pth file, if we follow the current setuptools implementation strategy).
> I think this is probably true, given the requirements in case 6 (which I
> agree with). So if you want an in-place install that's globally
> accessible, you'd need write access to global site-packages.

Basically write the .pth entry for the build to a site (the standard
lib module) recognized location.

>> * Case 4
> Right, although the requirement for that story is that you don't have to
> re-run the develop command after every pull; if you develop-install it
> once, you can simply pull more code changes in and they'll immediately
> be available. I've added a line to that story to make it more clear.

Ah, this case impacts the decision being made in issue 12279
(http://bugs.python.org/issue12279). The decision is to write a RECORD
file or not. We wouldn't write a RECORD if you want to be able to
update without rerunning the develop command. But this would be
invalid based on PEP 376 guidelines. Please post your thoughts about
this in that issue.

The wiki page has been edited to note what the develop command will
write to the file system. I'll restate it here as well...

The develop command writes three pieces of information to the filesystem:
 1. It calls upon the build action(s) to build the package relative to
the package's root directory.
 2. It calls the [build|install]_distinfo action to write the
.dist-info metadata inside the build directory. (see also Issue 12279)
 3. It adds the build directory's path to a .pth file.

Thanks Carl

--

___
Python tracker 

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

[issue12539] multiprocessing.Event.wait(n) doesn't time out properly

[mokrates]

New submission from mokrates :

Following is my problem:
I have two processes, connected via multiprocessing.Event
The one waits for the other with .wait(300). After 300 seconds it should look 
if there's work, even if it has not been awoken by the other process.
So. This runs on my Laptop, and when I fold it shut, sending it to suspend, and 
open it again, lets say, 10 minutes later (which are 600 seconds), then the 
.wait()-timeout has already gone. I would assume, cause it's a /timeout/ that 
it should then fire ASAP, but it fires never. The worker process is just frozen 
and has to be awoken by .set()ing the Event.

I workarounded it by creating another thread, which uses time.sleep(300) 
instead of multiprocessing.Event.wait(300) to wait 300 seconds and some glue to 
put it all together.

some stats:
me@mybox:~$ python2.7
Python 2.7.1+ (default, Apr 20 2011, 22:33:39) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
me@mybox:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux testing (wheezy)
Release:testing
Codename:   wheezy

--
messages: 140165
nosy: mokrates
priority: normal
severity: normal
status: open
title: multiprocessing.Event.wait(n) doesn't time out properly
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue11561] "coverage" of Python regrtest cannot see initial import of libs

[Brett Cannon]

Brett Cannon  added the comment:

Which I have not forgotten about. Just waiting until I have the time to get
to this.

On Mon, Jul 11, 2011 at 08:50, Éric Araujo  wrote:

>
> Éric Araujo  added the comment:
>
> Thanks for your work on this.  I made some minor comments on Rietveld (you
> should get an email), waiting for the real import experts to comment on the
> meat of the patch.
>
> --
> nosy: +eric.araujo
>
> ___
> Python tracker 
> 
> ___
>

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

___
Python tracker 

___Which I have not forgotten about. Just waiting until I have the time to get to 
this.On Mon, Jul 11, 2011 at 08:50, Éric 
Araujo rep...@bugs.python.org> 
wrote:


Éric Araujo mer...@netwok.org> 
added the comment:

Thanks for your work on this.  I made some minor comments on Rietveld (you 
should get an email), waiting for the real import experts to comment on the 
meat of the patch.

--
nosy: +eric.araujo

___
Python tracker rep...@bugs.python.org>
http://bugs.python.org/issue11561>
___

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

[issue12537] mailbox's _become_message is very fragile

[José María Ruiz Aguilera]

José María Ruiz Aguilera  added the comment:

Hi, I will be working on this issue. This is the first time I will work on a 
issue in Python so please patient.

--
nosy: +josemaria

___
Python tracker 

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

[issue12538] Extending int class

[R. David Murray]

R. David Murray  added the comment:

To set the value of an immutable type you must use the __new__ method.  By the 
time __init__ is called the value has already be established, and in the case 
of int it defaults to 0.

--
nosy: +r.david.murray
resolution:  -> invalid
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

[issue12538] Extending int class

[João Bernardo]

New submission from João Bernardo :

I'm having trouble subclassing the int type and I think this behavior is a 
bug... (Python 3.2)

>>> class One(int):
def __init__(self):
super().__init__(1)

>>> one = One()
>>> one + 2
2
>>> one == 0
True

I know `int` objects are immutable but my `One` class should be mutable... and 
why it doesn't raise an error?

That gives the same result on Python 2.7 using super properly.

Also, if that's not a bug, how it should be done to achieve "one + 2 == 3" 
without creating another attribute.

Things I also tried:
self.real = 1  #readonly attribute error
int.__init__(self, 1)  #same behavior

I Couldn't find any related issues... sorry if it's repeated.

--
components: Interpreter Core
messages: 140161
nosy: JBernardo
priority: normal
severity: normal
status: open
title: Extending int class
type: behavior
versions: Python 2.7, Python 3.2

___
Python tracker 

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

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[R. David Murray]

R. David Murray  added the comment:

One can argue that it is necessary to read the traceback in reverse order, so 
that reading the chain in reverse order is a logical extension of that.  So I 
guess I have no serious objection to this being rejected.

--

___
Python tracker 

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

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Benjamin Peterson]

Benjamin Peterson  added the comment:

There _is_ no full traceback for the first exception. It stops as soon as it's 
handled.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[R. David Murray]

R. David Murray  added the comment:

I think the reason the chained tracebacks look backward to me is twofold: I'm 
used to the last one in the list being the *only* one I get (in python2), and 
the last one in the list is often the one I want to deal with first.  This is 
especially true if my try/except is transforming the 
more-specific-but-not-application-meaningful exception into one that is 
meaningful for the application.

So another possibility would be to reverse the order in which the tracebacks 
are printed, and instead of saying "during the handling of the above 
exception...", we'd say "this exception occurred during the handling of the 
following exception:".  Doing this would probably greatly reduce the desire for 
a way to suppress the traceback chaining.

--
nosy: +ncoghlan

___
Python tracker 

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

[issue12537] mailbox's _become_message is very fragile

[Thomas Holmes]

Changes by Thomas Holmes :


--
nosy: +thomas.holmes

___
Python tracker 

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

[issue12537] mailbox's _become_message is very fragile

[R. David Murray]

New submission from R. David Murray :

The mailbox module has a method _become_message that copies attributes from an 
object that is an email.message.Message subclass to the calling object (which 
is also a subclass of email.message.Message).  This method is very fragile in 
the face of any changes to the email.message.Message attribute set.

Instead it would be better to decouple the mailbox and email modules by copying 
*all* __dict__ attributes from the source message to the new object, and then 
rewrite the _explain_to methods to not only convert the 'special attributes' to 
the correct format for the new subclass, but also delete any leftover "special" 
attributes.

--
components: Library (Lib)
keywords: easy
messages: 140157
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: mailbox's _become_message is very fragile
versions: Python 3.3

___
Python tracker 

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

[issue12167] test_packaging reference leak

[Vinay Sajip]

Vinay Sajip  added the comment:

I've created #12536 to cover the lib2to3 issue.

--

___
Python tracker 

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

[issue12536] lib2to3 BaseFix class creates un-needed loggers leading to refleaks

[Vinay Sajip]

New submission from Vinay Sajip :

See #12167 for background.

The BaseFix class creates a logger named with the filename when the 
set_filename method is called. This logger appears to never be used, but since 
set_filename could be called any number of times and loggers are effectively 
singletons and not garbage collected, this could lead to refleaks and unbounded 
memory usage for no benefit.

It's possible to output contextual information about a file being worked on 
without needing to create a logger with the filename.

I'm proposing that the references to the logger in BaseFix be removed, as the 
logger isn't used anyway, and the test suite runs without failures when the 
references are removed. This will allow progress on #12167.

--
components: 2to3 (2.x to 3.0 conversion tool), Library (Lib)
keywords: easy
messages: 140155
nosy: benjamin.peterson, eric.araujo, vinay.sajip
priority: normal
severity: normal
status: open
title: lib2to3 BaseFix class creates un-needed loggers leading to refleaks
type: behavior
versions: Python 3.3

___
Python tracker 

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

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Eric Snow]

Changes by Eric Snow :


--
nosy: +ericsnow

___
Python tracker 

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

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

[Eric Snow]

Changes by Eric Snow :


--
nosy: +ericsnow

___
Python tracker 

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

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

[Collin Winter]

Changes by Collin Winter :


--
nosy:  -collinwinter

___
Python tracker 

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

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

[Alec Koumjian]

Alec Koumjian  added the comment:

Thanks, Matthew. I did not realize I could access either of those. I should be 
able to build a helper function now to do what I want.

--

___
Python tracker 

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

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

[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

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[R. David Murray]

New submission from R. David Murray :

Consider the following traceback:

Traceback (most recent call last):
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 466, in 
__getattr__
return getattr(self._headers, key)
AttributeError: '_Header_List' object has no attribute 'header_factory'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/home/rdmurray/python/email6/Lib/mailbox.py", line 1631, in set_flags
self.replace_header('Status', status_flags)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 495, in 
replace_header
print('rep', self.header_factory)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 469, in 
__getattr__
self.__class__.__name__, key))
AttributeError: 'mboxMessage' object has no attribute 'header_factory'


The first traceback, which is supposed to be the "primary" error, gives
no indication of where the problem occured.  It starts with a fairly
deeply nested call.  The second traceback does show the line where the
error occured in the except statement, but you have to read the lines
above it to find the line that actually triggered the original
traceback.

I think it would be much better if either the full traceback were
given for the first traceback, or for both of them.  I realize
that the short traceback for the first traceback is how things
have "traditionally" worked when exceptions are caught, but as
evidenced by issue 1553375 this is often not the desired behavior
even before the existence of chained exceptions.

--
components: Interpreter Core
messages: 140153
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: Chained tracebacks are confusing because the first traceback is minimal
type: behavior
versions: 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

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

[Matthew Barnett]

Matthew Barnett  added the comment:

The new regex imlementation is hosted here: 
https://code.google.com/p/mrab-regex-hg/

The span of m['a_thing'] is m.span('a_thing'), if that helps.

The named groups are listed on the pattern object, which can be accessed via 
m.re:

>>> m.re
<_regex.Pattern object at 0x0161DE30>
>>> m.re.groupindex
{'another_thing': 3, 'a_thing': 1}

so you can use that to create a reverse dict to go from the index to the name 
or None. (Perhaps the pattern object should have such a .group_name attribute.)

--

___
Python tracker 

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

[issue8668] Packaging: add a 'develop' command

[Carl Meyer]

Carl Meyer  added the comment:

On 07/11/2011 09:17 AM, Michael Mulich wrote:
> * Cases 2, 3, 5 and 6 are strongly related. I'd suggest you condense them 
> into a single use case. I agree with case 2 and 6 most, but have questions:
> ** Why wouldn't one simply use a virtualenv? 

I don't know. I don't consider case 3 useful, because I don't consider
"I don't want to use a virtualenv" (without some clearer technical
justification) to be a prejudice the develop feature needs to support;
especially if supporting it essentially means re-implementing a
less-capable version of virtualenv within the develop command.

> -- Case 5 touches on this topic, but if we are installing in-place, who cares 
> if can place a development package in the global site-packages directory?

Several of these stories make the assumption that even the "in-place"
installation will require placing a file in the installation location (a
.pth file, if we follow the current setuptools implementation strategy).
I think this is probably true, given the requirements in case 6 (which I
agree with). So if you want an in-place install that's globally
accessible, you'd need write access to global site-packages.

> ** After the package has been installed in-place (using the develop command), 
> how does one identify it as an in development project (or in development 
> mode)? -- Case 3 and 6 touch on this topic (case 3 is a little vague at this 
> time), but doesn't explain what type of action is intended. So if we install 
> in-place (aka, develop), how does the python interpreter find the package? 
> Are we using PYTHONPATH at this point (which would be contradict a 
> requirement in  case 6)?

These use cases (probably intentionally) don't touch on specific
implementation strategies, but as I mentioned there's an implicit
assumption that a .pth file is the most likely strategy.

> * Case 4 is a be unclear. Is Carl, the actor, pulling unreleased remote 
> changes (hg pull --update) for these mercurial server plugins then running 
> the develop command on them? 

Right, although the requirement for that story is that you don't have to
re-run the develop command after every pull; if you develop-install it
once, you can simply pull more code changes in and they'll immediately
be available. I've added a line to that story to make it more clear.

> * Case 1 is good and very clear, but I'd consider it a feature rather than 
> required. Perhaps it should not be focused on first (priority). Thoughts?

I agree that's a second-level feature (or, perhaps more accurately, a
bug in the existing setuptools feature that I was hoping could be
addressed in the d2 version), not a primary requirement.

--

___
Python tracker 

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

[issue12534] Tkinter doesn't support property attributes

[R. David Murray]

R. David Murray  added the comment:

This is not a bug fix, but a feature request.  In Python3 the classes are of 
course new style.  So there's nothing to do here, sorry.

--
nosy: +r.david.murray
resolution:  -> out of date
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

[issue12534] Tkinter doesn't support property attributes

[Aaron Stevens]

Aaron Stevens  added the comment:

I forgot add that this is a problem only when inheriting from a Tkinter widget, 
such as a Frame.

--

___
Python tracker 

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

[issue12534] Tkinter doesn't support property attributes

[Aaron Stevens]

New submission from Aaron Stevens :

When using Tkinter in Python 2.6.6, it is impossible to use the new-style 
properties, as the base classes (Misc, Pack, Place, and Grid) do not use the 
new style classes.

It is easily fixed by changing the class declarations, i.e.:
  class Misc:
 becomes
  class Misc(object):

--
components: Tkinter
messages: 140148
nosy: bheklilr
priority: normal
severity: normal
status: open
title: Tkinter doesn't support property attributes
type: behavior
versions: Python 2.6

___
Python tracker 

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

[issue8668] Packaging: add a 'develop' command

[Alexis Metaireau]

Alexis Metaireau  added the comment:

Carl, I believe that's this one: http://wiki.python.org/moin/UsecasesOfDevelop

--

___
Python tracker 

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

[issue8668] Packaging: add a 'develop' command

[Carl Meyer]

Carl Meyer  added the comment:

Can someone post a link here to the page of use cases that Michael just 
reviewed? I think the link came through on the Fellowship mailing list, but I'm 
not quickly finding it...

--

___
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

[Michael Mulich]

Michael Mulich  added the comment:

On Mon, Jul 11, 2011 at 11:43 AM, Éric Araujo  wrote:
 > What do you mean with context?  Wouldn’t all three commands just
make install_distinfo generate files in the build dir?

Right, my context comment is invalid.

 > I think that option 4 is the most inelegant, and would be sad to see it win.
Ok... I forgot that we now have this RESOURCES file, which makes
leaving out the RECORD file less important, but still invalid based on
PEP 376.

So if we include the RECORD file (point number 2) without the checksum
and size (two columns in the RECORD csv format), we will still be
PEP376 valid (maybe?), but the file verification information will be
missing. And we don't really want this information because if we edit
a file, the checksum and size will be incorrect anyhow. This missing
information is not important when using the develop or test commands,
because we are running the commands on a trusted local copy. What are
the consequences of not writing the checksum or size to the RECORD
file? And does that solve the issue?

--

___
Python tracker 

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

[issue11561] "coverage" of Python regrtest cannot see initial import of libs

[Eric Snow]

Changes by Eric Snow :


--
nosy: +ericsnow

___
Python tracker 

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

[issue12509] test_gdb fails on debug build when builddir != srcdir

[Éric Araujo]

Éric Araujo  added the comment:

About 2.7: Can you please test?

--

___
Python tracker 

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

[issue12509] test_gdb fails on debug build when builddir != srcdir

[Éric Araujo]

Éric Araujo  added the comment:

Patch LGTM.

--
components: +Tests -None
nosy: +eric.araujo
versions: +Python 2.7, Python 3.3 -Python 3.1

___
Python tracker 

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

[issue12379] build outside source fail in head

[Éric Araujo]

Éric Araujo  added the comment:

FTR:
> Out-of-tree configure also fails because of missing .o files.
The solution is to remove the .o files.  Then one can run configure in a 
subdir, and later make.  This allows me to build in shared mode in a subdir, 
and have a regular build in the top level.

--

___
Python tracker 

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

[issue12436] Provide reference to detailed installation instructions

[Éric Araujo]

Éric Araujo  added the comment:

> Goal #1: set up Python
I believe http://docs.python.org/dev/using/ covers this.

> Goal #2: prepare a text editor
This is missing from our docs.  (My first thought was that it was out of scope, 
but for complete beginners, it would be nice to give a few pointers.)

> Goal #3: practice starting and exiting Python
The tutorial has one page about that.

> Goal #4: practice navigating the computer from a command prompt
Out of scope?

> Goal #5: practice running Python code from a file
This is probably in the tutorial or using docs, I have to check.

> Goal #6: get dependencies installed for the Saturday projects
This used to be non-standard, but now that we have packaging and pysetup, I 
translate this item to a doc bug: Explain how to use pysetup to get 
dependencies (in using, I think).

> Goal #7: start learning Python!
> Goal #8: Checkoff
Nothing to add, IMO.

--
nosy: +eric.araujo

___
Python tracker 

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

[issue12533] python-celementtree prevents me from running python develop.py to compile Imprudence Viewer

[Éric Araujo]

Éric Araujo  added the comment:

If there is a bug with distutils, xml.etree or CPython, then we need 
instructions on how to reproduce it.

If the bug can only happen with third-party ElementTree release, setuptools or 
Imprudence, then I’ll suggest you to go to the setuptools bug trackers (there 
is a fork, so there are two trackers) with your report.

--

___
Python tracker 

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

[issue12533] python-celementtree prevents me from running python develop.py to compile Imprudence Viewer

[Kristoffer Grundström]

Kristoffer Grundström  added the comment:

Well, I didn't know what do choose when I reported.
What more info do you need to help me put it in the right place?

--

___
Python tracker 

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

[issue12434] Strengthen 2.7 io types warning

[Éric Araujo]

Éric Araujo  added the comment:

Do you think the docstrings and error messages should be improved as well as 
the docs?

--
nosy: +eric.araujo

___
Python tracker 

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

[issue12533] python-celementtree prevents me from running python develop.py to compile Imprudence Viewer

[Éric Araujo]

Éric Araujo  added the comment:

setuptools bug are reported to these trackers: 
http://bugs.python.org/setuptools/ and 
https://bitbucket.org/tarek/distribute/issues

If a setuptools bugs comes from the underlying standard module, distutils, then 
this bug tracker is the right place, otherwise we can’t do anything.

--
nosy: +eric.araujo

___
Python tracker 

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

[issue12418] python should inherit the library search path from the compiler for stdlib extensions

[Éric Araujo]

Éric Araujo  added the comment:

> But maybe it would be enough to special case GCC as a unix compiler?
> At least there are already autoconf checks trying to detect gcc.

Yes, we could try that.  Steve, would you like to propose a patch?

--
nosy: +barry
versions: +Python 3.3

___
Python tracker 

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

[issue11561] "coverage" of Python regrtest cannot see initial import of libs

[Éric Araujo]

Éric Araujo  added the comment:

Thanks for your work on this.  I made some minor comments on Rietveld (you 
should get an email), waiting for the real import experts to comment on the 
meat of the patch.

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

[Michael Mulich]

Changes by Michael Mulich :


--
nosy:  -michael.mulich2

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

(It was probably the Roundup quotes bug.)

> The action needs to be called with an install, develop or test
> context, so I think item four is our best option.

What do you mean with context?  Wouldn’t all three commands just make 
install_distinfo generate files in the build dir?

I think that option 4 is the most inelegant, and would be sad to see it win.

--

___
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

[michael mulich]

michael mulich  added the comment:

Gmail decided to strip the quotes... Grr...

  > So, what do we do?
  > 1) don’t generate RECORD at all → invalid PEP 376
We have to generate a RECORD, otherwise resource lookups in
development and testing modes will fail or at least should fail.

  > 2) generate RECORD with paths to the files in the build dir
Yes, but that's not all.

  > 4) don’t add a build_distinfo command, just run install_distinfo
to the build dir from the test and develop commands

The action needs to be called with an install, develop or test
context, so I think item four is our best option.

--

___
Python tracker 

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

[issue11510] Peephole breaks set unpacking

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
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

[michael mulich]

michael mulich  added the comment:

We have to generate a RECORD, otherwise resource lookups in
development and testing modes will fail or at least should fail.

Yes, but that's not all.

> 4) don’t add a build_distinfo command, just run install_distinfo to the build 
> dir from the test and develop commands

The action needs to be called with an install, develop or test
context, so I think item four is our best option.

--
nosy: +michael.mulich2

___
Python tracker 

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

[issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue12420] distutils tests fail if PATH is not defined

[Éric Araujo]

Éric Araujo  added the comment:

Sorry, I don’t want to monkey-patch find_executable during tests.  We want the 
tests to work with the real code, with the same behavior and errors as real 
setup.py calls.  If a test does not work with python -E, then it should be 
skipped.

(Implementation idea:
  skip_if_empty_env = unittest.skipUnless(
  os.environ, 'test cannot run with an empty environment')
using sys.flags is not possible due to backward compatibility policy)

--

___
Python tracker 

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

[issue10403] Use "member" consistently

[Éric Araujo]

Changes by Éric Araujo :


--
status: closed -> open

___
Python tracker 

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

[issue12344] Add **kwargs to get_reinitialized_command

[Éric Araujo]

Éric Araujo  added the comment:

> The patch I attached does not violate the style guidelines that you
> indicate in the comments.

Then it’s good.  I was hurrying for my train, so I didn’t check your patch but 
wanted to reference my comments somewhere before I forgot them.

--

___
Python tracker 

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

[issue12449] Add accelerator "F" to button "Finish" in all MSI installers made by bdist_msi

[Éric Araujo]

Éric Araujo  added the comment:

> Apparently -m packaging.run and pysetup3 run don't perform
> identically, but that isn't relevant for this bug.
That’s very surprising, given that they have the same one-line code.  Please 
file that bug.

> Regarding bdist, I got bdist_wininst to work but I had to modify the
> code in place, it did not work by default.
Can you report that too, if there is no existing bug?  (Maybe it’s #10945 or 
another one.)

> It also creates an exe installer, not an MSI.
Why would you think it creates an MSI?  bdist_wininst is not bdist_msi.

> bdist_msi is not set as a valid command to run inside the commands
> package __init__.py.
Is it a problem?  In distutils too, bdist_msi is not registered in 
command.__init__, as it can’t run on non-Windows, but the bdist command knows 
that it exists and can run it.  IOW, there are two registries of bdist 
commands: in command.__init__, which is used by --help-commands and others, and 
in bdist.  In distutils, calling bdist --formats=msi or directly bdist_msi 
works (on Windows); if it doesn’t work with packaging, this is another bug to 
report.

--

___
Python tracker 

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

[issue8668] Packaging: add a 'develop' command

[Michael Mulich]

Michael Mulich  added the comment:

After looking over the use cases, these are my findings and questions:

* Cases 2, 3, 5 and 6 are strongly related. I'd suggest you condense them into 
a single use case. I agree with case 2 and 6 most, but have questions:
** Why wouldn't one simply use a virtualenv? -- Case 5 touches on this topic, 
but if we are installing in-place, who cares if can place a development package 
in the global site-packages directory?
** After the package has been installed in-place (using the develop command), 
how does one identify it as an in development project (or in development mode)? 
-- Case 3 and 6 touch on this topic (case 3 is a little vague at this time), 
but doesn't explain what type of action is intended. So if we install in-place 
(aka, develop), how does the python interpreter find the package? Are we using 
PYTHONPATH at this point (which would be contradict a requirement in  case 6)?

* Case 4 is a be unclear. Is Carl, the actor, pulling unreleased remote changes 
(hg pull --update) for these mercurial server plugins then running the develop 
command on them? 

* Case 1 is good and very clear, but I'd consider it a feature rather than 
required. Perhaps it should not be focused on first (priority). Thoughts?

--

___
Python tracker 

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

[issue12533] python-celementtree prevents me from running python develop.py to compile Imprudence Viewer

[Kristoffer Grundström]

Kristoffer Grundström  added the comment:

This is valid in Mageia, a fork of Mandriva.
Using 2.6.38.8-desktop-4.mga as kernel.
Arch is x86_64

The link to the imprudence wiki is here:

http://wiki.kokuaviewer.org/wiki/Imprudence:Compiling

Get the latest code for Imprudence here: git clone 
git://github.com/imprudence/imprudence.git

--

___
Python tracker 

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

[issue12533] python-celementtree prevents me from running python develop.py to compile Imprudence Viewer

[Kristoffer Grundström]

New submission from Kristoffer Grundström :

I went to the wiki of Imprudence Viewer & then I went to the Compiling-part. 
Then I downloaded latest code from git. I installed everything needed. Then I 
went into Desktop/imprudence/linden/indra & wrote python develop.py & that 
resulted in this: http://pastebin.mandriva.com/23157

I then tried to import using the interpreter, but still I got the same issue.

I then uninstalled python-celementtree & ran python develop.py & then 
everything went on OK.

--
components: Interpreter Core
messages: 140126
nosy: Kristoffer.Grundström
priority: normal
severity: normal
status: open
title: python-celementtree prevents me from running python develop.py to 
compile Imprudence Viewer
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue12344] Add **kwargs to get_reinitialized_command

[Thomas Holmes]

Thomas Holmes  added the comment:

> See also three comments about style on 
> http://bugs.python.org/review/8668/diff2/2845:3011/7845

I'm not sure I follow? The patch I attached does not violate the style 
guidelines that you indicate in the comments. The only failing I see is that 
get_reinitialized_command inside cmd.py does not have a doc string. I was 
following the path of minimal change, but I will be happy to add one.


Unless I am misunderstanding something about the other style comments I will 
work up another version with subcommand kwargs, docstring, and tests.

Thanks again Éric

--

___
Python tracker 

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

[issue12449] Add accelerator "F" to button "Finish" in all MSI installers made by bdist_msi

[Thomas Holmes]

Thomas Holmes  added the comment:

I was having a separate difficulty with bdist. Apparently -m packaging.run and 
pysetup3 run don't perform identically, but that isn't relevant for this bug.

Regarding bdist, I got bdist_wininst to work but I had to modify the code in 
place, it did not work by default. It also creates an exe installer, not an MSI.

bdist_msi is not set as a valid command to run inside the commands package 
__init__.py.

--

___
Python tracker 

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

[issue12518] In string.Template it's impossible to transform delimiter in the derived class

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I don't know that anybody relies on the current behavior and computers are now 
a bazillion times faster than they were in 2004, so who needs that micro 
optimization any more?

--

___
Python tracker 

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

[issue12344] Add **kwargs to get_reinitialized_command

[Éric Araujo]

Éric Araujo  added the comment:

> In Distributions.get_reinitialized_command should the
> reinitialization of the subcommands also get passed the kwargs?
Yes, the kwargs need to be passed all the way.

> Unfortunately my understanding of the (sub)command flow is not rock
> solid.
Some methods on the command classes are just convenience wrappers for methods 
on the distribution object.  That’s why I propose here that the real work is 
done in Distribution.get_reinitialized_command, and that 
Command.get_reinitialized_command just delegates.

> What are your thoughts on an effective test for this?
Create a command obj with some options.  Call get_reinitialized_command.  Check 
that its options have the default values, not the values set on the first 
command obj.

Do the same thing a second time, this time with some kwargs.  Check they’re set 
on the resulting command obj.

See also three comments about style on 
http://bugs.python.org/review/8668/diff2/2845:3011/7845

--

___
Python tracker 

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

[issue12167] test_packaging reference leak

[Éric Araujo]

Éric Araujo  added the comment:

Let me clarify my position: I think there is a bug in lib2to3 that should be 
fixed, after what the refleak would go.  (I’ll report it soon if nobody does it 
before.)  If Benjamin rejects the bug, then I’ll agree with the monkey-patch.

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

[issue12452] deprecation process in plistlib

[Éric Araujo]

Éric Araujo  added the comment:

Let’s keep one report per bug.  Please open another one for sysconfig, with Mac 
and distutils maintainers as nosy.

--
nosy: +eric.araujo
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
title: reuse plistlib in sysconfig; deprecation process in plistlib -> 
deprecation process in plistlib

___
Python tracker 

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

[issue12449] Add accelerator "F" to button "Finish" in all MSI installers made by bdist_msi

[Éric Araujo]

Éric Araujo  added the comment:

What do you mean with disabled?  There is a bdist_wininst command in packaging. 
 Use “pysetup run bdist_wininst” to call it.

--

___
Python tracker 

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

[issue12518] In string.Template it's impossible to transform delimiter in the derived class

[Éric Araujo]

Éric Araujo  added the comment:

See 629200d880ea for answers.

--
nosy: +eric.araujo

___
Python tracker 

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

[issue5996] abstract class instantiable when subclassing dict

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> rhettinger
priority: normal -> low

___
Python tracker 

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

[issue12532] PyPI server index names with '/' in them

[Michael Mulich]

Changes by Michael Mulich :


--
type:  -> behavior

___
Python tracker 

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

[issue12532] PyPI server index names with '/' in them

[Michael Mulich]

New submission from Michael Mulich :

Forward slashes show up in a project's (packaging.pypi.dist.ReleaseList) name 
when using a crawler (packaging.pypi.simple.Crawler) against, say and Apache 
index page. The packaging.tests:/pypiserver/foo_bar_baz directory is a perfect 
example of this type of data, but it isn't used anywhere in the current tests.

If a crawl is run on the index, results will come back with '/' in there name.

The issue was found when I was attempting to use a Crawler against the 
packaging.tests.pypi_server.PyPIServer in my package's tests.

--
assignee: tarek
components: Distutils2
files: test_name.py
messages: 140117
nosy: alexis, eric.araujo, michael.mulich, tarek
priority: normal
severity: normal
status: open
title: PyPI server index names with '/' in them
versions: Python 3.3
Added file: http://bugs.python.org/file22621/test_name.py

___
Python tracker 

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

[issue11435] Links to source code should now point to hg repo

[Éric Araujo]

Éric Araujo  added the comment:

Patch to fix links in the 3.2 docs.

--
Added file: http://bugs.python.org/file22620/docs-source-link-3.2.diff

___
Python tracker 

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

[issue11682] PEP 380 reference implementation for 3.3

[Nick Coghlan]

Nick Coghlan  added the comment:

I moved my personal sandbox from hg.python.org to bitbucket, so it should be 
easier for folks to build off the work in progress. (And fixed the typo in 
Renaud's name - I at least had it right in ACKS. I also reworded the draft 
attribution text in What's New)

I skimmed Benjamin's comments and basically agree with them. I've marked issue 
11816 as a dependency as some of the new tests will be easier to refactor once 
dis.get_opinfo() is available.

--
dependencies: +Refactor the dis module to provide better building blocks for 
bytecode analysis
hgrepos: +40

___
Python tracker 

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

[issue5996] abstract class instantiable when subclassing dict

[Eugene Toder]

Eugene Toder  added the comment:

They are, when there's a most specific metaclass -- the one which is a subclass 
of all others (described here 
http://www.python.org/download/releases/2.2.3/descrintro/#metaclasses, 
implemented here 
http://hg.python.org/cpython/file/ab162f925761/Objects/typeobject.c#l1956). 
Since ABCMeta is a subclass of type this holds.

Also, in the original example there's no multiple inheritance at all.

--

___
Python tracker 

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

[issue12517] Large file support on Windows: sizeof(off_t) is 32 bits

[Ross Lagerwall]

Changes by Ross Lagerwall :


--
nosy: +rosslagerwall

___
Python tracker 

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

[issue12494] subprocess: check_output() doesn't close pipes on error

[Ross Lagerwall]

Changes by Ross Lagerwall :


--
nosy: +rosslagerwall

___
Python tracker 

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

[issue12531] documentation index entries for * and **

[Peter Eisentraut]

New submission from Peter Eisentraut :

The existing documentation index entries for * and ** only point to their use 
in function definitions but not to their use in function calls.  I was looking 
for the latter, and it was difficult to find without this.  Here is a small 
patch to add the additional entries.

--
assignee: docs@python
components: Documentation
files: python-doc-index-**.patch
keywords: patch
messages: 140113
nosy: docs@python, petere
priority: normal
severity: normal
status: open
title: documentation index entries for * and **
versions: Python 3.3
Added file: http://bugs.python.org/file22619/python-doc-index-**.patch

___
Python tracker 

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

[issue8639] Allow callable objects in inspect.getfullargspec

[Michael Foord]

Michael Foord  added the comment:

I can produce a patch w/ tests and documentation for you to review Nick.

--

___
Python tracker 

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

[issue8639] Allow callable objects in inspect.getfullargspec

[Nick Coghlan]

Nick Coghlan  added the comment:

This API has changed around a bit in 3.x, so it is actually 
inspect.getfullargspec that needs to change (getargspec will inherit the new 
behaviour though, since it uses getfullargspec internally)

With appropriate docs and tests updates, I don't see a problem with adding the 
feature, though. Docs should note and tests should ensure that this only goes 
one level deep - if __call__ isn't a real function either, inspect shouldn't 
try to follow the descriptor chain down the rabbit hole. Anything else runs the 
risk of infinite recursion in the face of things like 
"inspect.getargspec(list)".

--
title: Allow callable objects in inspect.getargspec -> Allow callable objects 
in inspect.getfullargspec

___
Python tracker 

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

[issue11682] PEP 380 reference implementation for 3.3

[Renaud Blanch]

Renaud Blanch  added the comment:

I can not comment on http://bugs.python.org/review/11682/, so a quick comment 
here: Doc/whatsnew/3.3.rst patch gives me credit together with Greg Ewing for 
the implementation, but I've only upgraded his patches to 3.3.
So, the following line:
+(Implementation by Greg Ewing and Renauld Blanch)
should really be:
+(Implementation by Greg Ewing)

And, as I'm on it, the proper spelling for my surname is Renaud (not Renauld as 
it also appears in the commit message :)

--

___
Python tracker 

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

[issue1982] Feature: extend strftime to accept milliseconds

[R. David Murray]

R. David Murray  added the comment:

You are better off opening a new issue as a feature request.  Do add at least 
belopolsky as nosy on the new issue.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue5996] abstract class instantiable when subclassing dict

[Raymond Hettinger]

Raymond Hettinger  added the comment:

IIRC, classes weren't supposed to be able inherit from two classes that had 
different metaclasses (since differing metaclasses don't necessarily play well 
with one another).

--
nosy: +rhettinger

___
Python tracker 

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

[issue12530] cpython 3.3, __class__ missing.

[R. David Murray]

R. David Murray  added the comment:

Unless you can point to a place where the behavior that was fixed is actually 
documented, this is classed as an implementation detail that was changed (or, 
more likely, a bug that was fixed).  If this were less obscure or had been in 
existence for longer, there might be an argument for documenting it, but I'm 
surprised that anyone noticed this variable, since its existence is not in 
keeping with how Python works in general.  In fact, it goes completely against 
my Python intuition that it worked at all.  (I suppose that someone newer to 
Python would be more likely to find it by accident...)

That said, it is certainly not obvious from Misc/NEWS that this variable went 
away, so it was presumably fixed as part of some other change.  Given that we 
*do* have a bug report about it, we should consider if it should be documented 
somewhere; perhaps an addendum to the relevant Misc/NEWS entry, and then the 
What's New author can decide whether or not to include it.

(As an aside, note that What's New is not kept up to date, it generally only 
gets filled in closer to the release date.)

--
nosy: +r.david.murray

___
Python tracker 

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

[issue8639] Allow callable objects in inspect.getargspec

[Michael Foord]

Michael Foord  added the comment:

Doesn't seem like an unreasonable request. Nick / Benjamin, what do you think?

--

___
Python tracker 

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

[issue9329] freeze tool cannot handle JSON module properly

[Elazar Leibovich]

Elazar Leibovich  added the comment:

Similar problem occurs if you do not specify

   from encodings import ascii

You can get

   LookupError: unknown encoding: ascii

--
nosy: +Elazar.Leibovich
status: pending -> open

___
Python tracker 

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

[issue12523] 'str' object has no attribute 'more' [/usr/lib/python3.2/asynchat.py|initiate_send|245]

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Actually, the error is that in Python 3 you should use bytes objects when 
transmitting/receiving data over the network, not (unicode) strings.
That is, replace '\r\n' with b'\r\n', etc.

Of course, the error message should be made less obscure.

--
nosy: +pitrou
versions: +Python 3.3

___
Python tracker 

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