[issue15870] PyType_FromSpec should take metaclass as an argument

[Antoine Pitrou]

Antoine Pitrou added the comment:

> If filling out a type with all slots one-by-one is considered too
> tedious, and patching ob_type too hacky - here is another approach:
> Use FromSpec to create a type with all slots filled out, then call the
> metatype to create a subtype of that. I.e. the type which is based on
> a metatype would actually be a derived class of the type which has the
> slots defined.

As a matter of fact, this is what the io module is doing (except that
the derived type is written in Python). It does feel like pointless
complication, though.

--

___
Python tracker 

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

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

[Steven Bethard]

Steven Bethard added the comment:

Interesting idea! The regex would need a little extra care to interoperate 
properly with prefix_chars, but the approach doesn't seem crazy. I'd probably 
call the constructor option something like "args_default_to_positional" (the 
current behavior is essentially that args default to optional arguments if they 
look like optionals).

I'd be happy to review a patch along these lines. It would probably be good if 
Anders Kaseorg could also review it to make sure it fully solves his problem.

--

___
Python tracker 

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

[issue15874] argparse cannot parse shell variable arguments in file-given arguments

[Steven Bethard]

Steven Bethard added the comment:

You could try declaring a type converter and using the type= parameter of 
add_argument. Your type converter could look something like:

def expanded_path(arg):
return os.path.expandvars(arg)

Would that work?

--

___
Python tracker 

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

[issue15876] test_curses refleak

[Ross Lagerwall]

Changes by Ross Lagerwall :


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

[issue15878] struct long type size

[Сергей Ковба]

New submission from Сергей Ковба:

Such code PackageFile.write(struct.pack( "l", PkgHdrSize)) have different 
behaviour on 32-bit and 64-bit systems.
In case 32-bit system it writes to file 4 bytes. and 8 bytes in case 64-bit 
system, but in http://docs.python.org/library/struct.html p.7.3.2.2 long type 
have strict 4-byte size.

--
messages: 169980
nosy: Сергей.Ковба
priority: normal
severity: normal
status: open
title: struct long type size
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

[issue15878] struct long type size

[Mark Dickinson]

Mark Dickinson added the comment:

This is expected behaviour.  By default, struct.pack and struct.unpack use the 
*native* size and alignment.  Use "http://docs.python.org/library/struct.html#byte-order-size-and-alignment

--
nosy: +mark.dickinson
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

[issue15877] xml.dom.minidom cannot parse ISO-2022-JP

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

This is similar to issue13612: pyexpat does not support multibytes encodings.

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue14900] cProfile does not take its result headers as sort arguments

[Arne Babenhauserheide]

Arne Babenhauserheide added the comment:

What would be the best way to get this patch reviewed?

--

___
Python tracker 

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

[issue14900] cProfile does not take its result headers as sort arguments

[Andrew Svetlov]

Andrew Svetlov added the comment:

I'll take a look next week if nobody else do it before.

--

___
Python tracker 

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

[issue12370] Use of super overwrites use of __class__ in class namespace

[Nick Coghlan]

Nick Coghlan added the comment:

OK, I think I have a way to fix this that will actually *reduce* the level of 
special casing needed in the compiler.

Specifically, I think we may be able to make the class statement emit *two* 
scopes, rather than the current one. The outer scope would be created with 
MAKE_CLOSURE, and thus names defined there would participate in lexical 
scoping. The inner scope would use the current MAKE_FUNCTION behaviour, and 
thus names defined there would be ignored by lexical scoping. "__class__" would 
then be defined in the outer scope *after* the class has been created. It would 
roughly like the following, except with __qualname__ still set correctly:

>>> def outer():
... class inner:
... def method(self):
... print(the_class)
... the_class = inner
... return inner
...
>>> cls = outer()
>>> cls.method()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: method() missing 1 required positional argument: 'self'
>>> cls().method()
.inner'>

The one potential wrinkle I see is whether this might cause a semantic change 
for name references from the class body to a containing function, but I think 
the technique is at least worth trying.

If this works, __class__ would just become a completely ordinary cell 
reference, and override it at class scope should work again. super() itself 
would still need magic to handle the automatic lookup of the first positional 
argument to the calling function, but at least the symtable magic should be 
able to go away.

--

___
Python tracker 

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

[issue15867] make importlib documentation easier to use

[Chris Jerdonek]

Changes by Chris Jerdonek :


--
title: It's hard to decypher how to build off of the provided objects from the 
importlib docs -> make importlib documentation easier to use

___
Python tracker 

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

[issue15879] set.__or__, __and__, etc create subclass types, but ignore __new__

[Jon Obermark]

New submission from Jon Obermark:

If they are not going to call the __metaclass__ or the class __new__, then they 
should return `set` objects instead of subclass objects, so that it is clear 
what is going on.

As it is, the results of set operations receive some subclass information but 
not all.  So they are not really obeying the notion of a subclass: the results 
are neither `set` objects, nor properly-constructed objects of the `set` 
subclass.

e.g. 
class Fooset(Set):
  def __new__(cls, s = []):
print 'New called'
self = super(Fooset, cls).__new__(cls)
self.update(s)
if isinstance(s, Fooset):
  self.foo = s.foo
else:
  self.foo = 'default'
return self

x = Fooset([1,2,5])
y = x|x


The object `y` reports being of the type `Fooset`, but has not been constructed 
by the `type` that makes `Fooset` objects.

--
messages: 169986
nosy: Jon.Obermark
priority: normal
severity: normal
status: open
title: set.__or__, __and__, etc create subclass types, but ignore __new__

___
Python tracker 

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

[issue15867] make importlib documentation easier to use

[Julian Berman]

Julian Berman added the comment:

Eric: Yeah I've seen that, it's the one thing that I kept open as I was turning 
back and forth through the various parts of importlib. So yeah I like that 
document certainly at least a bit :). Also thanks to both you and Brett for 
linking that issue, that's certainly something I'll keep an eye on.

Just to repeat the specific things that perhaps we could work on -- I strongly 
agree that the top of importlib's docs would benefit from reworking the See 
Also at the top. Also, perhaps that monumental undertaking would be a thing 
that could be wrangled :P -- like you said, import hooks seem to have two broad 
use cases: changing *where* a module comes from away from a simple file 
containing Python source code on a filesystem, and secondly changing what 
happens when a module is being imported. So I guess what I would love to have 
would be an example for each of those. An example of a Loader that loaded from 
somewhere else other than a file, and an example of an Importer that did 
something else when executing. I'm sure you'll correct me if I've missed an 
important one. If that's reasonable sounding and I manage to succeed in my own 
use case, perhaps I'll take a shot at that.

One thing I certainly understand here is that usually I (we) wouldn't have this 
problem since blog posts and other third party documentation and code can 
provide examples that are helpful enough to help developers get a sense of what 
they need to write. The thing for me here was that I didn't really find 
anything helpful in that sector. importlib is new obviously, so maybe what's 
given me trouble will be mitigated after 3.3 gets released and a few people 
write up some examples on their own.

I recognize that there was a huge undertaking here, and that it's still being 
honed, I hope in no way did this sound disparaging :). Also I hope it didn't 
sound like a misplaced StackOverflow post -- although certainly the 
confirmation that I was on the right track should help me finish this off quite 
easily, so thanks for that as well :).

--

___
Python tracker 

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

[issue15874] argparse cannot parse shell variable arguments in file-given arguments

[R. David Murray]

R. David Murray added the comment:

I had forgotten all about os.path.expandvars.  Note, however, that that 
function is very naive:

  >>> os.path.expandvars("'$HOME'")
  "'/home/rdmurray'"

That is, it is doing unconditional substitution, not parsing shell syntax.  It 
should work well for simple cases, though.

It might be worth throwing up a trial balloon on python-ideas for adding 
something to shlex that would do a "better" job of environment variable 
substitution for the version of shell syntax that shlex supports, which would 
therefore become a sort of platform-independent syntax for doing this.

--

___
Python tracker 

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

[issue15879] set.__or__, __and__, etc create subclass types, but ignore __new__

[R. David Murray]

R. David Murray added the comment:

It is probably true that this is a bug, but subclasses of mutable classes do 
not normally override __new__.  (I'm curious what your use case is for doing 
so.)

--
nosy: +benjamin.peterson, r.david.murray

___
Python tracker 

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

[issue15880] os.path.split() and long UNC names

[Kalle Rutanen]

New submission from Kalle Rutanen:

On Windows, long-UNC paths are needed to inspect and modify paths with more 
than 260 characters. The os.path.split() function behaves incorrectly in the 
presence of a long-UNC prefix //?/ or \\?\. Consider iterating d = 
os.path.split(d)[0] with d = '//?/e:/python-test/dir'. Then the values of d are 
as follows:

'//?/e:/python-test/dir'
'//?/e:/python-test'
'//?/e:'
'//?'
'//'

The two last splits are the incorrect ones, where the splitting should end at 
'//?/e:'.

One consequence of this is that os.makedirs(d) crashes, because it attempts to 
run os.mkdir('//') at the bottom of its recursion. The same thing happens when 
replacing all / with \\ in the above.

--
components: Library (Lib)
messages: 169990
nosy: kaba2
priority: normal
severity: normal
status: open
title: os.path.split() and long UNC names
type: crash
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

[issue15879] set.__or__, __and__, etc create subclass types, but ignore __new__

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

This was already fixed (in the 3.x releases) by issue1721812.

--
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed
superseder:  -> A subclass of set doesn't always have __init__ called.

___
Python tracker 

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

[issue15880] os.path.split() and long UNC names

[Kalle Rutanen]

Kalle Rutanen added the comment:

By inspecting the code for os.path.split() in ntpath.py, one sees that the 
problem is actually in os.path.splitdrive(), which does not handle long-UNC 
paths.

--

___
Python tracker 

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

[issue12067] Doc: remove errors about mixed-type comparisons.

[Mike Hoy]

Changes by Mike Hoy :


--
nosy: +mikehoy

___
Python tracker 

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

[issue12370] Use of super overwrites use of __class__ in class namespace

[Eric Snow]

Eric Snow added the comment:

Wouldn't the following also start working (currently a NameError)?

  class X:
  def f(self):
  print(f.__qualname__)
  def g(self):
  f(None)

  X().f()
  X().g()

How about this[1] (also currently a NameError):

  class Outer:
 class Inner:
 class Worker:
 pass
 class InnerSubclass(Inner):
 class Worker(Inner.Worker):
 pass

I wouldn't mind the semantic change, but it would be a change nonetheless.


[1] See http://mail.python.org/pipermail/python-list/2011-April/601605.html

--
nosy: +eric.snow

___
Python tracker 

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

[issue12370] Use of super overwrites use of __class__ in class namespace

[Eric Snow]

Eric Snow added the comment:

Actually, that second would still not work (it would have to pass through the 
non-lexical inner scope that Nick mentioned).  Is that also the case for the 
first one?

--

___
Python tracker 

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

[issue15880] os.path.split() and long UNC names

[Kalle Rutanen]

Kalle Rutanen added the comment:

It seems to me that this problem can be fixed by replacing splitdrive with 
splitunc at line 170 in ntpath.py.

--

___
Python tracker 

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

[issue6178] Core error in Py_EvalFrameEx 2.6.2

[Chris Kaynor]

Chris Kaynor added the comment:

Was any resolution found for this? I am debugging some intermittent crashes now 
which have the same visible callstack as Tim reported.

tstate->frame is NULL on line 2717 of ceval.c

I am using an in-house compiled Python 2.6.4, compiled with Visual Studio 2008, 
compiled for x64 and running on Windows 7.

The Python code that appears to be executing is calling into the pywin32 module 
a number of times.

--
nosy: +Chris.Kaynor

___
Python tracker 

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

[issue15879] set.__or__, __and__, etc create subclass types, but ignore __new__

[Jon Obermark]

Jon Obermark added the comment:

The closing author is correct, the use case is adequately covered by __init__, 
and that has been fixed in 3.  It makes sense this will not be backported.

--

___
Python tracker 

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

[issue6178] Core error in Py_EvalFrameEx 2.6.2

[Tim Savannah]

Tim Savannah added the comment:

As an update (since someone else has this problem) this issue stopped once we 
converted from centos to archlinux (www.archlinux.org). May be an underlying 
issue with something in the centos environment. We used the same modules same 
configuration basically same compilation for python.

--

___
Python tracker 

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

[issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles

[Martin v . Löwis]

Martin v. Löwis added the comment:

I think the patch for issue 15645 was incorrect. Instead of generating the 
pickles in the source tree and copying them, it should have arranged lib2to3 to 
generate them in the target directory instead (just as all the compileall 
invocations also generate files in LIBDEST).

There are multiple ways to achieve this. The least intrusive (perhaps) is to 
insert "$(DESTDIR)$(LIBDEST)" into sys.path before importing lib2to3 in the 
Makefile.

The approach that I suggest is to make lib2to3.pgen2.driver a script which 
expects a .txt path, and generates a pickle next to it, so the installation 
would do

$(PYTHON_FOR_BUILD) -m lib2to3.pgen2.driver 
$(DESTDIR)$(LIBDEST)/lib2to3/Grammar.txt
$(PYTHON_FOR_BUILD) -m lib2to3.pgen2.driver 
$(DESTDIR)$(LIBDEST)/lib2to3/PatternGrammar.txt

--
nosy: +loewis

___
Python tracker 

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

[issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6)

[Martin v . Löwis]

Martin v. Löwis added the comment:

I disagree that the regression is critical. IIUC, it fails on systems without 
urandom, such as Tru64 and HPUX. However, failure to support such systems is 
*not* critical, IMO; I think that OS-specific failures should be considered 
critical only if they occur on Linux, Windows, or OSX.

So I suggest that the priority of this issue is reduced.

More relevant than breaking HPUX is, IMO, that urandom is actually documented 
to raise NotImplementedError, so the patch looks good. For best compatibility, 
the actual spelling of the error message from 2.6 should be restored.

I'm puzzled by 

https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=KRNG11I

which claims that HPUX 11.11 (at least) *does* have /dev/urandom. Maybe your 
installation doesn't have KRNG11i in /etc/loadmods?

Also, the claim that it breaks Tru64 contradicts with

http://en.wikipedia.org/wiki//dev/random

which claims that Tru64 5.1B (at least) does have /dev/urandom.

--
nosy: +loewis

___
Python tracker 

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

[issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6)

[Martin v . Löwis]

Martin v. Löwis added the comment:

An interesting question is whether the patch should be applied to 2.6 and 3.1. 
It is not a security fix in itself, which suggests that it shouldn't apply. 
OTOH, it's a follow-up to an earlier security fix.

--

___
Python tracker 

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

[issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6)

[Ian Wienand]

Ian Wienand added the comment:

I'm not sure what systems are defined as critical or not.

Although python is not really installable/configurable by end-users on ESXi, I 
noticed during development because we use python very early in the boot, before 
/dev/urandom appears for us (it comes from a kernel module loaded later).

--

___
Python tracker 

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

[issue15881] multiprocessing 'NoneType' object is not callable

[Chris McDonough]

New submission from Chris McDonough:

The symptom is an exact duplicate of the symptom reported in the following 
(closed) issue:

http://bugs.python.org/issue9775

The issue is also related to the following other issues:

http://bugs.python.org/issue4106
http://bugs.python.org/issue9205
http://bugs.python.org/issue9207

To reproduce the symptom driving the patches that will be attached to this 
issue:

  git clone git://github.com/pypa/pip.git
  cd pip
  /any/python setup.py dev
  /any/python setup.py test

You can either wait for the entire test suite to finish or you can press ctrl-C 
at any time (the tests take a long time).  In either case, a traceback like the 
following will be printed to the console.

  Error in atexit._run_exitfuncs:
  Traceback (most recent call last):
File "/home/chrism/opt/Python-2.7.3/lib/python2.7/atexit.py", line 24, in 
_run_exitfuncs
func(*targs, **kargs)
File "/home/chrism/opt/Python-2.7.3/lib/python2.7/multiprocessing/util.py", 
line 284, in _exit_function
  info('process shutting down')
  TypeError: 'NoneType' object is not callable
  Error in sys.exitfunc:
  Traceback (most recent call last):
File "/home/chrism/opt/Python-2.7.3/lib/python2.7/atexit.py", line 24, in 
_run_exitfuncs
  func(*targs, **kargs)
File "/home/chrism/opt/Python-2.7.3/lib/python2.7/multiprocessing/util.py", 
line 284, in _exit_function
  info('process shutting down')
  TypeError: 'NoneType' object is not callable

>From what I understand in other issues, multiprocessing.util._exit_function 
>shouldn't actually be called *after*  the containing module's globals are 
>destroyed (it should be called before), but this does indeed happen.

Patches will be attached that anticipate the symptom and prevent a shutdown 
error.  One will be attached for Python 2.7 branch, the other for the Python 
tip.   Each causes functions that are called at shutdown time to keep a 
reference around to other functions and globals used within the function, and 
each does some checks for the insane state and prevents an error from happening 
in this insane state.

--
components: Library (Lib)
messages: 170003
nosy: mcdonc
priority: normal
severity: normal
status: open
title: multiprocessing 'NoneType' object is not callable
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

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

[issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6)

[The Written Word]

The Written Word added the comment:

We're running Tru64 UNIX 5.1A, not 5.1B which definitely doesn't have 
/dev/urandom.

--

___
Python tracker 

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

[issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6)

[The Written Word]

The Written Word added the comment:

We do not have KRNG11i installed. It did not ship with the original 
installation of HP-UX 11.11. It needs to be loaded after-the-fact and we cannot 
be ensured that our customers will have this module installed nor do we wish to 
make it a requirement.

--

___
Python tracker 

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

[issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default.

[Terry J. Reedy]

Terry J. Reedy added the comment:

Enhancements can only be targeted at 3.4, where robotparser is now 
urllib.robotparser

I wonder if documenting the simple solution would be sufficient.

--
nosy: +orsenthil, terry.reedy
versions: +Python 3.4 -Python 2.7

___
Python tracker 

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

[issue15851] Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default.

[Terry J. Reedy]

Terry J. Reedy added the comment:

In any case, a doc change *could* go in 2.7 and 3.3/2.

--

___
Python tracker 

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

[issue15881] multiprocessing 'NoneType' object is not callable

[Richard Oudkerk]

Changes by Richard Oudkerk :


--
nosy: +sbt

___
Python tracker 

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

[issue15881] multiprocessing 'NoneType' object is not callable

[Chris McDonough]

Chris McDonough added the comment:

Patch for tip.

--
keywords: +patch
Added file: http://bugs.python.org/file27142/shutdown_typeerror-tip.patch

___
Python tracker 

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

[issue15881] multiprocessing 'NoneType' object is not callable

[Chris McDonough]

Chris McDonough added the comment:

2.7 branch patch.

--
Added file: http://bugs.python.org/file27143/shutdown_typeerror-27.patch

___
Python tracker 

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

[issue15881] multiprocessing 'NoneType' object is not callable

[Mark Dickinson]

Changes by Mark Dickinson :


--
stage:  -> patch review
versions:  -Python 2.6, Python 3.1

___
Python tracker 

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

[issue15863] Fine-grained info about Python versions which support changes introduced in micro releases

[Terry J. Reedy]

Terry J. Reedy added the comment:

I do not think there should be references between the Python 2 docs and Python 
3 docs. But within each, I think it ok to have exceptional multiple references 
for what is, I believe, a unique situation: a security fix that required a new 
feature. Do it however seems most graceful.

My first thought was that someone seeing "added in 2.6.8' should know that 
adding a feature in a bugfix release is almost never done, hence it might not 
be in 2.7.0. But then I remembered that this fix is mainly for web sites, and 
the reader selecting which Python versions to use might not be a Python 
programmer.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue15863] Fine-grained info about Python versions which support changes introduced in micro releases

[Andrew Svetlov]

Andrew Svetlov added the comment:

Well, the patch is welcome.

--

___
Python tracker 

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

[issue15865] reflect bare star * in function signature documentation

[Terry J. Reedy]

Terry J. Reedy added the comment:

By looking at x.py, I confirmed that the added stars are correct.
Also, the correction of 'header' to 'hdr' is correct.

However, for threading.py in 3.3.0, I see

class Thread:
...
def __init__(self, group=None, target=None, name=None,
 args=(), kwargs=None, *, daemon=None):

whereas the patch and existing .rst

-.. class:: Thread(group=None, target=None, name=None, args=(), kwargs={},
+.. class:: Thread(group=None, target=None, name=None, args=(), kwargs={}, \
   verbose=None, *, daemon=None)

has an extra 'verbose=None' that should be removed there and in any explanatory 
text that follows.

(The fact that we found 2 doc signature errors other than the 4 missing *s 
suggests that we need a tool to systematically compare doc signature to code 
signature.)

--
nosy: +terry.reedy

___
Python tracker 

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

[issue15865] reflect bare star * in function signature documentation

[Chris Jerdonek]

Chris Jerdonek added the comment:

Thanks, Terry.  If anyone is curious, it looks like the verbose keyword 
argument was added to the docs (and to threading.py) in revision f71acc4b2341, 
and then subsequently removed (but not from the docs) in revision 8ec51b2e57c2.

> (The fact that we found 2 doc signature errors other than the 4 missing *s 
> suggests that we need a tool to systematically compare doc signature to code 
> signature.)

Out of curiosity, can anyone summarize what our existing tooling might already 
be able to do in this regard (e.g. Sphinx or pydoc)?

I will update the patch.

--

___
Python tracker 

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

[issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6)

[Roundup Robot]

Roundup Robot added the comment:

New changeset 2e8b01583839 by Antoine Pitrou in branch '3.2':
Issue #15340: Fix importing the random module when /dev/urandom cannot be 
opened.
http://hg.python.org/cpython/rev/2e8b01583839

New changeset a53fc9982e2a by Antoine Pitrou in branch 'default':
Issue #15340: Fix importing the random module when /dev/urandom cannot be 
opened.
http://hg.python.org/cpython/rev/a53fc9982e2a

--
nosy: +python-dev

___
Python tracker 

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

[issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6)

[Roundup Robot]

Roundup Robot added the comment:

New changeset edbf37ace03c by Antoine Pitrou in branch '2.7':
Issue #15340: Fix importing the random module when /dev/urandom cannot be 
opened.
http://hg.python.org/cpython/rev/edbf37ace03c

--

___
Python tracker 

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

[issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6)

[Antoine Pitrou]

Antoine Pitrou added the comment:

Ok, this is now fixed in 3.2/3.3/2.7. I'll leave it to Martin and Benjamin 
whether this should be backported to 2.6 and 3.1.
(Georg, this changeset should probably be ported to 3.3.0 too)

--
priority: release blocker -> high
versions:  -Python 2.7, 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

[issue15882] _decimal.Decimal constructed from tuple

[Aaron]

New submission from Aaron:

I think I may have found a problem with the code that constructs Infinity from 
tuples in the C _decimal module.

# pure python (3.x or 2.x)
>>> decimal.Decimal( (0, (0, ), 'F'))
Decimal('Infinity')

# _decimal
>>> decimal.Decimal( (0, (0, ), 'F'))
Traceback (most recent call last):
  File "", line 1, in 
decimal.InvalidOperation: []

Also, there is no unit test coverage for constructing these special values from 
tuples either.  I have provided some that pass with the existing pure python 
code and with the modifications to the _decimal C code.

The unit tests can be applied to Python 2.7.x as well, if desired.  They would 
go in the ExplicitConstructionTest.test_explicit_from_tuples() method.

--
components: Extension Modules
files: _decimal.diff
keywords: patch
messages: 170017
nosy: hac.man
priority: normal
severity: normal
status: open
title: _decimal.Decimal constructed from tuple
versions: Python 3.3
Added file: http://bugs.python.org/file27144/_decimal.diff

___
Python tracker 

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

[issue15882] _decimal.Decimal constructed from tuple

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +skrah

___
Python tracker 

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

[issue14900] cProfile does not take its result headers as sort arguments

[Arne Babenhauserheide]

Arne Babenhauserheide added the comment:

Thank you!

--

___
Python tracker 

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

[issue12370] Use of super overwrites use of __class__ in class namespace

[Nick Coghlan]

Nick Coghlan added the comment:

Yep. The only name in the new scope would be "__class__". Everything else,
including method names, should remain invisible from method bodies. I'm not
100% sure it will work as we want, but that's because I'm not sure if we
can avoid causing a semantic change for classes at module scope. I just
figure it's worth trying.

--

___
Python tracker 

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

[issue15865] reflect bare star * in function signature documentation

[Chris Jerdonek]

Chris Jerdonek added the comment:

Here is an updated patch that incorporates Terry's suggestion.

--
Added file: http://bugs.python.org/file27145/issue-15865-2.patch

___
Python tracker 

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

[issue12370] Use of super overwrites use of __class__ in class namespace

[Eric Snow]

Eric Snow added the comment:

sounds like it would be worth a shot

--

___
Python tracker 

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

[issue15881] multiprocessing 'NoneType' object is not callable

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

The patch makes sense.  I'll take another look over the weekend, but it seems 
to be ready to be applied.

--
assignee:  -> belopolsky
nosy: +belopolsky
stage: patch review -> commit review

___
Python tracker 

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

[issue15881] multiprocessing 'NoneType' object is not callable

[Chris Jerdonek]

Chris Jerdonek added the comment:

+# NB: we hold on to references to functions in the arglist due to the

This is a nit, but I think adding "NB:", "Note:", etc. to the beginning of a 
comment is redundant because by being a comment it is already implicit that it 
should be noted.

--
nosy: +cjerdonek

___
Python tracker 

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

[issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles

[Ronald Oussoren]

Ronald Oussoren added the comment:

See als Issue15838.

--

___
Python tracker 

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

[issue15645] 2to3 Grammar pickles not created when upgrading to 3.3.0b2

[Ronald Oussoren]

Ronald Oussoren added the comment:

See also Issue15838

--

___
Python tracker 

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

[issue15822] installed python may fail incorrectly trying to rebuild lib2to3 grammar pickles

[Ronald Oussoren]

Ronald Oussoren added the comment:

The other alternative to fix this is to revert the patch in issue 15645  and 
then remove the -E flag from PYTHON_FOR_BUILD.

PYTHON_FOR_BUILD was introduced by a, possibly incomplete, attempt to introduce 
support for cross compiling. In particular, the variable was introduced in 
issue 14330. Neither the patch, nor the tracker discussion explains why the -E 
is necessary. It might be because all uses of $(BUILDPYTHON) that were replaced 
by PYTHON_FOR_BUILD had the -E flag at the time.

BTW. There also doesn't seem to documentation for cross building.

--

___
Python tracker 

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

[issue15340] OSError with "import random" when /dev/urandom doesn't exist (regression from 2.6)

[Georg Brandl]

Georg Brandl added the comment:

Now picked into the 3.3.0 release clone as 6a782496f90a.

--

___
Python tracker 

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

[issue15781] test_threaded_import fails with -j4

[Georg Brandl]

Georg Brandl added the comment:

Now picked into 3.3.0 release clone as 85070f284fd2.

--

___
Python tracker 

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

[issue15784] OSError.__str__() should distinguish between errno and winerror

[Georg Brandl]

Georg Brandl added the comment:

Done in 4e941113e4fa.

--
status: open -> closed

___
Python tracker 

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

[issue15785] curses.get_wch() returns keypad codes incorrectly

[Georg Brandl]

Georg Brandl added the comment:

Now picked into 3.3.0 release clone in 23377e88487b.

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

___
Python tracker 

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

[issue15828] imp.load_module doesn't support C_EXTENSION type

[Georg Brandl]

Georg Brandl added the comment:

Picked as 4f6f59303146 and a4a9c5717204.

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

___
Python tracker 

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

[issue14223] curses addch broken on Python3.3a1

[Georg Brandl]

Georg Brandl added the comment:

Done in d6d632f254ee.

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

___
Python tracker 

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

[issue15847] parse_args stopped accepting tuples

[Georg Brandl]

Georg Brandl added the comment:

Committed in release clone as 8c2e87aeb707.  Please apply to the main branches 
as usual.

--
priority: release blocker -> high

___
Python tracker 

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

[issue13992] Segfault in PyTrash_destroy_chain

[Georg Brandl]

Georg Brandl added the comment:

Picked as 5aa1bc2f00ad.

--
status: open -> closed

___
Python tracker 

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

[issue15882] _decimal.Decimal constructed from tuple

[Stefan Krah]

Stefan Krah added the comment:

Infinities do not have payloads. It's a bug in decimal.py that it
accepts non-empty coefficients when constructing infinities.

Since there was a corresponding unit test for as_tuple(), I've
kept the wrong representation for _decimal:

# XXX non-compliant infinity payload.
d = Decimal("Infinity")
self.assertEqual(d.as_tuple(), (0, (0,), 'F') )


But this unit test is only executed for the Python version:

# XXX coefficient in infinity should raise an error
if self.decimal == P:
d = Decimal( (0, (4, 5, 3, 4), 'F') )
self.assertEqual(d.as_tuple(), (0, (0,), 'F'))
d = Decimal( (1, (0, 2, 7, 1), 'F') )
self.assertEqual(d.as_tuple(), (1, (0,), 'F'))


My suggestion is to disallow non-empty tuples for decimal.py
and change the infinity tuple to (0, (), 'F').

--
nosy: +mark.dickinson

___
Python tracker 

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