[issue17914] add os.cpu_count()

[Charles-François Natali]

Charles-François Natali added the comment:

> Well, they can be wrong sometimes, too :-)

Indeed, as can I ;-)

> The patch doesn't seem to rely on the glibc, so we are fine here.
> Or do the other libs work likewise?

sysconf(_SC_NPROCESSORS_CONF) is implemented with the above function
in the glibc.

For other Unix systems apparently they use the sysctl() syscall, and I
don't *think* it can fail to return the number of CPUs. So the only
platforms where it could in theory fail are things like Cygwin, etc.

>
>> And the DSL processor takes care of the rest.
>>
>> What does this become if your return object isn't typed?
>
> It's typed, just the type is "int or None". I'm sure some
> statically-typed languages are able to express this (OCaml? Haskell?).

I recently started learning Haskell. You have Either and Maybe that
could fall into that category.

> Anyway, I don't mind whether it's None or 0 or -42. But let's not hide
> the information.

I liked your suggestion of making it an enum:

>>> os.cpu_count()


Nah, None is fine to me!

--

___
Python tracker 

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

[issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals

[paul j3]

paul j3 added the comment:

I've played a bit the idea that barthard sketched.  I don't have all the 
details worked out, but I believe this is what will happen:

With

  parser = argparse.ArgumentParser()
  parser.add_argument('-w')
  parser.add_argument('-x', nargs='+')
  parser.add_argument('y')
  parser.add_argument('z', nargs='*')

some possible parses are

'-w 1 -x 2 3 4 5', # w:1, x:[2,3,4], y:5, z:[] -
   # fail +
'-w 1 2 -x 3 4 5', # w:1, y:2, x:[3 4 5], z:[] +

'-w 1 -x 2 3', # w:1, x:[2], y:3, z:[] -
   # fail +
'-x 1 2 -w 3 4 5 6',   # w:3, x:[1,2], y:4, z:[5,6] +
   # w:3, x:[1], y:2, z:[4,5,6] -

'-x 1 2 3 4 -w 5 6 7', # w:5, x:[1,2,3,4], y:5, z:[7] +
   # w:5, x:[1,2,3], y:4, z:[6,7] -

'1 2 3 -x 4 5 -w 6',   # w:6, x:[4,5], y:1, z:[2,3] +
  
'+' lines are those currently produced
'-' lines are ones that would be produced by these ideas

'-w 1 -x 2 3 4 5' is the protypical problem case.  The current parser allocates 
all [2,3,4,5] to -x, leaving none for y, thus failing.  So desired solution is 
to give 5 to y, leaving -x with the rest.

'-x 1 2 -w 3 4 5 6' is a potentially ambiguous case.  The current parser lets 
-x grab [1,2]; y then gets 4, and z the remainder.  But the alternative is to 
give 2 to y, leaving -x with just [1].

In this case 
arg_strings_pattern = 'OAAO'

replacing the Os with the option flags: '-xAA-w'

I match this with a refined version of bethard's regex:

pat1='((?:-wA)|(?:-xA+)|(?:-wA-xA+)|(?:-xA+-wA))'
pat = _re.compile('%s?(?PA)%s?(?PA*)%s?'%(pat1,pat1,pat1))

groups (without the Nones) and groupdict are

['-xA', 'A', '-wA', 'AAA']
{'z': 'AAA', 'y': 'A'}

So this does effectively give y the 2nd argument, leaving -x with just the 1st.

The current parser effectively groups the arguments as

['-xAA, '-wA', 'A', 'AA']

In the real world, generating and apply a global pattern like this could get 
complicated.  For example there are long option names ('--water'), and combined 
argument strings ('-x1', '-x=1').

--

___
Python tracker 

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

[issue17954] Support creation of extensible enums through metaclass subclassing

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue17959] Alternate approach to aliasing for PEP 435

[Nick Coghlan]

Nick Coghlan added the comment:

I just wanted to note that there's a trivial way to prevent accidental aliases 
inline or in your test suite if you don't intend them:

class MyEnum(Enum):


assert len(MyEnum) == len(MyEnum.__members__)

--

___
Python tracker 

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

[issue17642] IDLE add font resizing hot keys

[Roger Serwy]

Roger Serwy added the comment:

@Abhishek: I'd rather not require extensions to have a new method for resetting 
font sizes. Instead, a virtual event can be bound to a callback by the 
extension if it needs to know about a font change.

@Alejandro: It looks like there's a bug in ZoomFont.py where the cursor can go 
off screen which has propagated into these patches. That's my fault.

I'll take a look at these points later this week.

--

___
Python tracker 

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

[issue13657] IDLE doesn't support sys.ps1 and sys.ps2.

[Roger Serwy]

Roger Serwy added the comment:

Adding 16123 as a dependency. Resolving sys.ps1 and sys.ps2 will likely be 
simpler when only considering one execution mode.

--
dependencies: +IDLE - deprecate running without a subprocess
nosy: +roger.serwy
versions: +Python 2.7, Python 3.4

___
Python tracker 

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

[issue14146] IDLE: source line in editor doesn't highlight when debugging

[Roger Serwy]

Roger Serwy added the comment:

On second thought, I'll wait until after the releases so that Misc/NEWS gets 
populated properly.

--

___
Python tracker 

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

[issue17972] inspect module leak docs

[xiaobing jiang]

New submission from xiaobing jiang:

the inspect module leak docs.
all these functions have no doc.
getlineno
getabsfile
getblock
formatannotation
walktree
findsource
indentsize
getargs
formatannotationrelativeto
classify_class_attrs

--
assignee: docs@python
components: Documentation
messages: 189193
nosy: docs@python, s7v7nisla...@gmail.com
priority: normal
severity: normal
status: open
title: inspect module leak docs
type: enhancement
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

[issue14146] IDLE: source line in editor doesn't highlight when debugging

[Roger Serwy]

Roger Serwy added the comment:

It won't make it in 2.7.5. Benjamin tagged the 2.7.5 release a couple of days 
ago.

I'll apply this later tonight.

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

[issue17968] memory leak in listxattr()

[Benjamin Peterson]

Benjamin Peterson added the comment:

Technically a false alarm but it is a danger in the future.

--
status: open -> closed

___
Python tracker 

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

[issue17968] memory leak in listxattr()

[Roundup Robot]

Roundup Robot added the comment:

New changeset 7aa157971810 by Benjamin Peterson in branch '3.3':
prevent double free in cleanup code (#17968)
http://hg.python.org/cpython/rev/7aa157971810

New changeset 617cb2f978b0 by Benjamin Peterson in branch 'default':
merge 3.3 (#17968)
http://hg.python.org/cpython/rev/617cb2f978b0

--

___
Python tracker 

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

[issue17968] memory leak in listxattr()

[Christian Heimes]

Christian Heimes added the comment:

Coverity complains that your patch has introduced a double free bug. Can you 
have a look, please?

** CID 1021198: Double free (USE_AFTER_FREE)
/Modules/posixmodule.c: 10161
http://scan5.coverity.com:8080//sourcebrowser.htm?projectId=10226#mergedDefectId=1021198



CID 1021198: Double free (USE_AFTER_FREE)

/Modules/posixmodule.c: 10123 ( freed_arg)
   10120
   10121if (length < 0) {
   10122if (errno == ERANGE) {
>>> "free(void *)" frees "buffer".
   10123PyMem_FREE(buffer);
   10124continue;
   10125}
   10126path_error(&path);
   10127break;
  

/Modules/posixmodule.c: 10161 ( double_free)
   10158exit:
   10159path_cleanup(&path);
   10160if (buffer)
>>> CID 1021198: Double free (USE_AFTER_FREE)
>>> Calling "free(void *)" frees pointer "buffer" which has already been freed.
   10161PyMem_FREE(buffer);
   10162return result;
   10163}
   10164
   10165#endif /* USE_XATTRS */

--
nosy: +christian.heimes
status: closed -> open

___
Python tracker 

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

[issue17947] Code, test, and doc review for PEP-0435 Enum

[Nick Coghlan]

Nick Coghlan added the comment:

Thanks Guido, now that I fully understand your reasoning, I can accept that
this is a valid "practicality beats purity" situation.

--

___
Python tracker 

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

[issue17971] Weird interaction between Komodo Python debugger C module & Python 3

[Eric Promislow]

Eric Promislow added the comment:

I'm running it inside gdb to see if I can figure it out.

I don't see a way of isolating this from the whole product.

--

___
Python tracker 

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

[issue16024] Doc cleanup regarding path=fd, dir_fd, follow_symlinks, etc

[Kaleb Robertson]

Kaleb Robertson added the comment:

Adding a revision of the .diff file according to akuchling's comment.

--
nosy: +kkvr05
Added file: 
http://bugs.python.org/file30255/lch.supports_set.doc.cleanup.1-revised.diff

___
Python tracker 

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

[issue17971] Weird interaction between Komodo Python debugger C module & Python 3

[Benjamin Peterson]

Benjamin Peterson added the comment:

Since this seems to be some sort of interaction between Komodo's code and 
Python (it works for me with vanilla Python 3), it's going to be hard to debug 
without seeing what this other thing is doing.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue17971] Weird interaction between Komodo Python debugger C module & Python 3

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +georg.brandl, ncoghlan

___
Python tracker 

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

[issue17914] add os.cpu_count()

[Yogesh Chaudhari]

Yogesh Chaudhari added the comment:

Based on the last 3 messages by Ned, Charles and Antoine, I keep thinking that 
arguments made by Charles are very valid ones and that it would be better to 
return 1. I say this (partly from the 'type' argument, but), mainly, *if* its 
known that the underlying libraries are returning 1 on failure. *If* that is 
the case I see no reason try to return None (which, btw, will never happen if 
none of the calls return non-positive values ever).

--

___
Python tracker 

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

[issue17971] Weird interaction between Komodo Python debugger C module & Python 3

[Eric Promislow]

New submission from Eric Promislow:

While much of Komodo's source code has been released under MIT/GPL/LGPL, the 
Python debugger hasn't, so I can't post it here.  We can work out an 
arrangement later, although it might not be necessary once I describe 
the problem:

Komodo's Python debugger was a pure-Python debugger, based on pdb. To make it 
possible to debug the Chandler app, one of the components was written in C 
against the CPython API, for performance, and all was good. 

With Python 3, breakpoints no longer work after an exec with an explicit
globals arg, where globals is a user-supplied dict, not "globals()" or 
"locals()".  For example, in this code:

print("I'm line 1")
namespace = {}
exec("a = 42", namespace)
print("I'm line 4")
print("Done")

Set breakpoints at lines 1 and 4. Start the debugger in
"Run" mode (stops at first breakpoint).  The debugger
stops at line 1.  Press continue. The debugger runs to
end, without stopping.

If the namespace arg to exec is deleted, or replaced with
"globals()" or "locals()",  (quotes are typographic, not literal),
the breakpoint at line 4 is honored. It only fails when globals
is set to a new dict.

Additionally, if the namespace is defined like so:
namespace = {"DBGPHide": 1}, the breakpoint is honored.
The debugger marks its internal frames with directives like
"DBGPHide" to avoid stepping into them.  Yes, it's a hack.

Adding more diagnostics to the C file shows that the first
time the debugger finds a frame with a global named DBGPHide,
__name__ is "dbgp.common".  This makes sense, because that
module sets DBGPHide to 1, but after every other time, __name__ is "__main__" , 
and DBGPHide isn't set on it.

I had a look at the implementation of exec in Python 3.3 in
bltinmodule.c and ceval.c, but don't see anything obvious.

Ref Komodo bug http://bugs.activestate.com/show_bug.cgi?id=98951

--
components: Interpreter Core
messages: 189183
nosy: ericp
priority: normal
severity: normal
status: open
title: Weird interaction between Komodo Python debugger C module & Python 3
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

[issue1772673] Replacing char* with const char*

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Antoine, I was referring to the discussion linked earlier
> (http://mail.python.org/pipermail/python-dev/2006-February/060689.html).

Ok, I've read it through. The problem is specifically with
pointers-to-pointers:
http://mail.python.org/pipermail/python-dev/2006-February/060849.html

And indeed, PyArg_ParseTupleAndKeywords() got its "const char **"
argument changed back to "char **". But the other consts have stayed
(such as the "const char *" argument to the same
PyArg_ParseTupleAndKeywords()).

So it looks like the patch, in essence, is legit.
(of course, in practice, it probably won't apply cleanly, since it's
very old; and perhaps it's incomplete too)

--

___
Python tracker 

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

[issue1772673] Replacing char* with const char*

[Eli Bendersky]

Eli Bendersky added the comment:

Antoine, I was referring to the discussion linked earlier 
(http://mail.python.org/pipermail/python-dev/2006-February/060689.html). Users 
of the C API needed to recompile their code and also add preprocessor hacks to 
make things compatible with C and C++, AFAIU.

--

___
Python tracker 

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

[issue17914] add os.cpu_count()

[Antoine Pitrou]

Antoine Pitrou added the comment:

> > Python's goal is not to emulate the suboptimal parts of other languages.
> 
> Well, I'm sure they could have returned -1 or 0, which are valid C
> long distinct from any valid integer representing a number of CPUs. If
> the libc guys (and many other APIs out there ), chose to return 1 as
> default, there's a reason.

Well, they can be wrong sometimes, too :-)

> Furthermore, you're missing the point: since the underlying libraries
> os.cpu_count() rely on return 1 when they can't determine the number
> of CPUs, why complicate the API by pretending to return None in that
> case, since you can't detect it in the first place?

The patch doesn't seem to rely on the glibc, so we are fine here.
Or do the other libs work likewise?

> And the DSL processor takes care of the rest.
> 
> What does this become if your return object isn't typed?

It's typed, just the type is "int or None". I'm sure some
statically-typed languages are able to express this (OCaml? Haskell?).

Anyway, I don't mind whether it's None or 0 or -42. But let's not hide
the information.

--

___
Python tracker 

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

[issue17914] add os.cpu_count()

[Charles-François Natali]

Charles-François Natali added the comment:

> Python's goal is not to emulate the suboptimal parts of other languages.

Well, I'm sure they could have returned -1 or 0, which are valid C
long distinct from any valid integer representing a number of CPUs. If
the libc guys (and many other APIs out there ), chose to return 1 as
default, there's a reason.

Furthermore, you're missing the point: since the underlying libraries
os.cpu_count() rely on return 1 when they can't determine the number
of CPUs, why complicate the API by pretending to return None in that
case, since you can't detect it in the first place?

>  We have dynamic typing, and so can return None from the same function that 
> returns 1.  And we have compact expressions like `cpu_count() or 1`, so we 
> don't have to make unfortunate compromises.

That's not because it's feasible that it's a good idea.

Dynamic typing is different from no typing: the return type of a
function is part of its API. You can't return None when you're
supposed to return an int. If I go to a coffee machine to get some
chocolate and there's no chocolate left, I don't want it to return me
a coffee instead.

What's looks more natural
if os.cpu_count() is None
or
if os.cpu_count() >= 1

Even in dynamic typing, it's always a good thing to be consistent in
parameter and return value type.

Why?
For example, PEP 362 formalizes function signatures.

With a os.cpu_count() returning a number (or eventually raising an
exception), the signature is:

def cpu_count() -> int
   [...]

What does it become if you can return None instead?

For example, there's some discussion to use such signatures or other
DSL to automatically generate the glue code needed to parse arguments
and return values from C extension modules (PEP 436 and 437).

Basically, you just implement:

/*
** [annotation]
** @return int
*/
long cpu_count_impl(void)
{
long result = 1;
#ifdef _SC_NPROCESSORS_CONF
long = sysconf(_SC_NPROCESSORS_ONL);
[...]
#fi
return result;
}

And the DSL processor takes care of the rest.

What does this become if your return object isn't typed?

Really, typing is of paramount importance, even in a dynamically typed language.

And pretending to return a distinct value is pretty much useless,
since the underlying platform will always return a default value of 1.
Plus `cpu_count() or 1` is really ugly.

Now I hope I made my point, but honestly at this point I don't care
anymore, since in practice it should never return None. Documenting
the None return value is just noise in the API...

--

___
Python tracker 

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

[issue1772673] Replacing char* with const char*

[Antoine Pitrou]

Antoine Pitrou added the comment:

> For external APIs visible to user code, this can cause some
> compatibility problems and users may need to at the very least
> re-compile this code.

Can you explain exactly which compatibility problems this would cause?

Actually, the point is precisely to make life easier for third-party code, 
since "const char *" is more accepting than "char *".

--
nosy: +pitrou
stage:  -> needs patch
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

[issue17941] namedtuple should support fully qualified name for more portable pickling

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

LGTM too.  Needs test and docs.

--

___
Python tracker 

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

[issue6208] path separator output ignores shell's path separator: / instead of \

[Terry J. Reedy]

Terry J. Reedy added the comment:

The resolution should be 'This is a gawd-awful mess created by Microsoft 30 
years ago and we already do the best we sensibly can to deal with it' ;-) (and 
sensible people know it would be a mess from the first day).

To put is another way, the answer to the original question 'can this be 
configured somehow' seems to be 'not obviously'.

--
resolution:  -> works for me
status: open -> closed

___
Python tracker 

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

[issue17947] Code, test, and doc review for PEP-0435 Enum

[Zachary Ware]

Zachary Ware added the comment:

I've come across something in the implementation here that I'd like some 
clarification on.  What is the purpose of overriding __dir__ in Enum and 
EnumMeta?  It doesn't change any behavior that I'm aware of, just makes things 
look a little nicer when someone calls dir() on their Enum.  And, in fact, it 
can make things a little confusing.  For example:

>>> class Test(enum.Enum):
... foo = 1
... bar = 2
... baz = 3
...
>>> dir(Test)
['__class__', '__doc__', '__members__', 'bar', 'baz', 'foo']
>>> Test.mro


This brings up another interesting case:

>>> class Test2(enum.Enum):
... mro = 1
... _create = 2
...
>>> dir(Test2)
['__class__', '__doc__', '__members__', '_create', 'mro']
>>> Test2.__members__
mappingproxy(OrderedDict([('mro', ), ('_create', )]))
>>> Test2['mro']

>>> Test2.mro

>>> Test2._create
>
>>>

>From using "mro" or "_create", I would have expected either ValueError or for 
>them to work properly.  I don't know whether this should be fixed (one way or 
>the other), documented, or just left alone; those kind of names really 
>shouldn't ever be used anyway.  It's something I stumbled across, though, and 
>I just wanted to make sure that those who do have opinions that matter are 
>aware of it :)

--

___
Python tracker 

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

[issue17945] tkinter/Python 3.3.0: peer_create doesn't instantiate Text

[Gregory HOULDSWORTH]

Gregory HOULDSWORTH added the comment:

The Text instance created by the last patch has the same parent -in
the Python w hierarchy- as the "model" widget regardless of the actual
parent implied by the given pathname. Further, pathname is really a tk
level construct: in Python this hierarchy is expressed the w's master
and name. Attached is a proposed fix; peer_create now has the
signature (self, master=None, cnf={}, **kw)
The optional name of the peer is passed as an item in cnf.
(note that the behaviour of peers is actually correct in the previous
incarnation, only the children property is faulty and you have to go
down to tk names to attach the text to an arbitrary parent)

There is also an issue with subclassing of Text, to override the
standard event handling for example. Should the peer be an instance of
that subclass, or should this be a 'default' that may be overriden?

--
Added file: http://bugs.python.org/file30254/peerfix.diff

___
Python tracker 

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

[issue17914] add os.cpu_count()

[Ned Batchelder]

Ned Batchelder added the comment:

Python's goal is not to emulate the suboptimal parts of other languages.  We 
have dynamic typing, and so can return None from the same function that returns 
1.  And we have compact expressions like `cpu_count() or 1`, so we don't have 
to make unfortunate compromises.

--

___
Python tracker 

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

[issue6208] path separator output ignores shell's path separator: / instead of \

[Eric V. Smith]

Eric V. Smith added the comment:

I say close it. Any "shell detection" is likely to be fragile, and any changes 
are likely to break something. It's not worth the risk.

--

___
Python tracker 

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

[issue17941] namedtuple should support fully qualified name for more portable pickling

[Guido van Rossum]

Guido van Rossum added the comment:

Great, forget I said anything then.

LGTM to the patch, feel free to commit (with update to Misc/NEWS please).

--

___
Python tracker 

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

[issue17914] add os.cpu_count()

[Antoine Pitrou]

Antoine Pitrou added the comment:

> And on Linux, 1 is returned as a fallback when you don't have the
> right /sys or /proc entry:
> http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getsysstats.c
> 
> (The enum discussion enlighted me, endless discussions are so fun!)

Do you want cpu_count() to return an enum?

>>> os.cpu_count()


--

___
Python tracker 

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

[issue17914] add os.cpu_count()

[Charles-François Natali]

Charles-François Natali added the comment:

Just for giggles, here's the glibc default implementation on non Linux
platforms:
http://sourceware.org/git/?p=glibc.git;a=blob;f=misc/getsysstats.c;hb=HEAD
"""
int
__get_nprocs ()
{
  /* We don't know how to determine the number.  Simply return always 1.  */
  return 1;
}
"""

And on Linux, 1 is returned as a fallback when you don't have the
right /sys or /proc entry:
http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getsysstats.c

(The enum discussion enlighted me, endless discussions are so fun!)

--

___
Python tracker 

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

[issue17941] namedtuple should support fully qualified name for more portable pickling

[Richard Oudkerk]

Richard Oudkerk added the comment:

When pickling a class (or instance of a class) there is already a check 
that the invariant

 getattr(sys.modules[cls.__module__], cls.__name__) == cls

holds.

 >>> import pickle
 >>> class A: pass
...
 >>> A.__module__ = 'nonexistent'
 >>> pickle.dumps(A())
Traceback (most recent call last):
   File "", line 1, in 
_pickle.PicklingError: Can't pickle : import of 
module 'nonexistent' failed

--

___
Python tracker 

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

[issue17941] namedtuple should support fully qualified name for more portable pickling

[Guido van Rossum]

Guido van Rossum added the comment:

I'd like to propose one slight tweak to the patch.  (Also to enum.py.)

If no module name was passed and _getframe() fails, can you set the __module__ 
attribute to something that will cause pickling the object to fail?  That would 
be much better than letting it pickle but then being unable to unpickle it.

(TBH I'm not sure how this should be accomplished, and if it can't, forget that 
I said it.  But it would be nice.)

--

___
Python tracker 

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

[issue6208] path separator output ignores shell's path separator: / instead of \

[Mark Lawrence]

Mark Lawrence added the comment:

Can this issue to confined to the small round filing cabinet, mainly on the 
grounds that I find some of the wording undecipherable?

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue17950] Dynamic classes contain non-breakable reference cycles

[Guido van Rossum]

Guido van Rossum added the comment:

I think turning the __mro__ tuple into a getter is fine.  As long as this works 
I'm okay:

class C: ...
mro = C.__mro__
del C
assert mro[0].__name__ == 'C'

(The last assert stands in for asserting that the class object must stay alive 
as long as the tuple returned by __mro__ is alive.)

I think it's also fine if the descriptors contain weak references.  Its hard to 
get a "raw" descriptor anyways -- you can't say C.desc, you'd have to say 
C.__dict__['desc'].

--
nosy: +gvanrossum

___
Python tracker 

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

[issue17970] Mutlithread XML parsing cause segfault

[Antoine Pitrou]

Changes by Antoine Pitrou :


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

[issue17947] Code, test, and doc review for PEP-0435 Enum

[Alex Gaynor]

Alex Gaynor added the comment:

>From PyPy's perspective we don't really care what you name this particular 
>bikeshed, and it's probably not that important to us (in this particular case).

As far as I know IronPython is the only Python VM that doesn't have _getframe() 
support by default (you need a CLI flag at startup, IIRC). In PyPy calling 
_getframe (right now) has a negative performance impact, but it's local to 
wherever you're calling it, so unless you create Enum in frequent loops (as 
opposed to just once at module level), this doesn't really matter to us.

If someone wants to invent a more narrow, tailored API for stack introspection, 
logging is a much better target (right now each call to 
logging.{info,error,etc.} calls _getframe(), which does have a real performance 
impact. (We'll eventually invent enough engineering to fix this ourselves, but 
in the meantime if somewhere were to pain this bikeshed, we certainly wouldn't 
object ;)).

--

___
Python tracker 

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

[issue17963] Deprecate the frame hack for implicitly getting module details

[Guido van Rossum]

Guido van Rossum added the comment:

As I explained in issue 17947, I think that any Python implementation worth its 
salt should be able to implement sys.get_calling_module_name() (*), at least 
for the case where the caller is top-level code in a module body.  That is a 
much weaker requirement than being able to implement sys._getframe().  We 
should just add this to CPython 3.4 and require that conforming implementations 
support it, at least in the stated context (top-level caller).

(*) Please pick a somewhat shorter name for it.

--
assignee: gvanrossum -> 

___
Python tracker 

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

[issue17970] Mutlithread XML parsing cause segfault

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

But this would break working code which already uses locks correctly (or some 
kind of pool of cached parsers)

--

___
Python tracker 

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

[issue17970] Mutlithread XML parsing cause segfault

[Alex Gaynor]

Alex Gaynor added the comment:

It could also track tids and raise an error if you attempt to use it from 
multiple threads.

--
nosy: +alex

___
Python tracker 

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

[issue17947] Code, test, and doc review for PEP-0435 Enum

[Guido van Rossum]

Guido van Rossum added the comment:

Here's the promised explanation why I want to keep the getframe hack.  I'm sure 
it won't satisfy everyone, but this will have to do.

There are two parts to my argument.  TL;DR: (a) by implementing this hack, we 
will maximize user happiness; (b) I expect that all Python implementations can 
provide the functionality needed.

So why does this maximize user happiness?  First of all, enums are such simple 
objects that it's a disgrace to have an enum that isn't picklable.  But most 
users are lazy and lack imagination, so if they find they have to do extra work 
to ensure that something is picklable, they will make a judgement call -- is 
the extra work to make it picklable worth it?  Unfortunately they will try to 
make this judgment call in a fraction of a second, and they limited imagination 
they may well say "I can't imagine ever pickling this", save themselves the 
work, and move on.  If you think more than a second about the decision, you've 
wasted more time than it takes to type "module=__name__", so it's going to be a 
split-second decision.  But nevertheless, having to think about it and typing 
it is a distraction, and when you're "in the zone" you may prefer to spend your 
time thinking about the perfect names for your enum class and values rather 
than the red tape of making in picklable.

So, in my mind, it's a given that there will be many enums that are missing the 
module=__name__ keyword argument.  Moreover, it's likely that most of the time 
this will be fine -- you can get through most days just fine without ever 
reading or writing a pickle.  (For example, I very much doubt that I've ever 
pickled one of the flag values used by the socket module to define e.g. the 
address family, socket type, or protocol.)

But now you enter a different phase of your project, or one of your 
collaborators does, or perhaps you've released your code on PyPI and one of 
your users does.  So someone tries to pickle some class instance that happens 
to contain an unpicklable enum.  That's not a great experience.  Pickling and 
unpickling errors are often remarkably hard to debug.  (Especially the latter, 
so I have privately admonished Ethan to ensure that if the getframe hack 
doesn't work, the pickle failure should happen at pickling time, not at 
unpickle time.)  Once you've tracked down the source, you have to figure out 
the fix -- hopefully just typing the error message into Google will link back 
to a StackOverflow answer explaining the need to say "module=__name__".  But 
the damage is done, especially if the person encountering the pickling error is 
not the original author of the code defining the enum.  (Often the person 
downloading and using a package from PyPI has less advanced Python knowledge 
than the pa
 ckage author, so they may have a hard time debugging the situation.)

You can see how having the getframe hack in place makes life more pleasant for 
many people -- the package user won't have to debug the pickling problem, and 
the package author won't have to deal with the bug report and fix.

But what about other Python implementations?  Well, TBH, they have plenty of 
other issues.  The reality is that you can't take a large package that hasn't 
been tested on Jython, or IronPython, or PyPy, and expect it to just work on 
any of those.  Sure, things are getting better.  But there are still tons of 
differences between the various Python implementations (as there are between 
different versions of CPython), and whether you like it or not, CPython is 
still the Python version of choice for most people.  The long and short of it 
is that porting any significant package to another implementation is a bit of 
work, and keeping the port working probably requires adding some set of 
additional line items to the style guide used by its developers -- don't use 
feature X, don't depend on behavior Y, always use pattern Z...


However, I don't expect that "always pass module=__name__ when using the enum 
convenience API" won't have to be added to that list.  sys._getframe() is way 
more powerful than what's needed.  Even on platforms where sys._getframe() is 
unimplementable (or disabled by default in favor of a 10% speedup), it should 
still be possible to provide an API that *just* gets the module name of the 
caller, at least in case the call site is top-level module code (and for 
anything else, the getframe hack doesn't work anyway).  After all, we're 
talking about a full Python implementation, right?  That's a dynamic language 
with lots of introspection APIs, and any implementation worth its salt will 
have to deal with that, even if full-fledged sys._getframe() is explicitly 
excluded.

So I propose that we use sys._getframe() for the time being, and the authors of 
Jython, IronPython and PyPy can get together and figure out how to implement 
something like sys.get_calling_module_name().  They have plenty of time -- at 
least until they pledge suppo

[issue17970] Mutlithread XML parsing cause segfault

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

Expat is not thread-safe at the object level, a single Parser cannot be used 
from multiple threads.
Pyexpat could add locks to Parser objects.

--
nosy: +amaury.forgeotdarc
stage:  -> needs patch

___
Python tracker 

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

[issue17966] Lack of consistency in PEP 8 -- Style Guide for Python Code

[Paul Jurczak]

Paul Jurczak added the comment:

I admit, it is somewhat silly, but not entirely silly.

--

___
Python tracker 

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

[issue17968] memory leak in listxattr()

[Roundup Robot]

Roundup Robot added the comment:

New changeset 2187cf880e5b by Antoine Pitrou in branch '3.3':
Issue #17968: Fix memory leak in os.listxattr().
http://hg.python.org/cpython/rev/2187cf880e5b

New changeset 1fa1a021ed23 by Antoine Pitrou in branch 'default':
Issue #17968: Fix memory leak in os.listxattr().
http://hg.python.org/cpython/rev/1fa1a021ed23

--
nosy: +python-dev

___
Python tracker 

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

[issue17968] memory leak in listxattr()

[Antoine Pitrou]

Antoine Pitrou added the comment:

Should be fixed now.

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

___
Python tracker 

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

[issue17936] O(n**2) behaviour when adding/removing classes

[Antoine Pitrou]

Antoine Pitrou added the comment:

One thing: "int i" should be "Py_ssize_t i".

--

___
Python tracker 

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

[issue17969] multiprocessing crash on exit

[Richard Oudkerk]

Richard Oudkerk added the comment:

> We can consider two options then:
> 1) A multiprocessing specific fix.  Removing this handle close gil 
> release (which is superfluous, since these calls aren't blocking in any 
> real sense) will certainly remove _this_ instance of the crash.  An 
> alternative is to make this worker thread non-daemon.  That shouldn't 
> be too hard and shouldn't have any other side effects.

Have you tried doing

p = Pool()
try:
...
finally:
p.close()   # or perhaps p.terminate()
p.join()

Actually, making the worker thread non-daemonic is not so simple.  This is 
because there is no way to interrupt a background thread which is blocked doing 
IO (unless you use multiplexing which is not possible with non-overlapped 
pipes).

One can try to unblock such background threads by reading/writing messages 
from/to the result/task pipe, but it not straightforward.

--

___
Python tracker 

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

[issue17969] multiprocessing crash on exit

[Antoine Pitrou]

Antoine Pitrou added the comment:

Le lundi 13 mai 2013 à 16:14 +, Kristján Valur Jónsson a écrit :
> I don't see the point of having 2.7 in bug fix mode if we can't fix
> bugs.

Delicate bug fixes may entail regressions, and we've had enough of them
in 2.7.4. You've already patched your own Python anyway.

--

___
Python tracker 

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

[issue17936] O(n**2) behaviour when adding/removing classes

[Kristján Valur Jónsson]

Kristján Valur Jónsson added the comment:

That is not sufficient.  The weakrefs may have been cleared already if the 
deletion comes as a result of garbage collection (which is currently the only 
way classes get deleted.)

It is still easily demonstratably correct:
The previous version _only_ removed subclasses on setting __bases__.  
Housekeeping of stale weakrefs was done when new classes were created.

This proposed version still properly removes subclasses when setting __bases__, 
but housekeeping of dead weakrefs is now moved to the point when a class is 
deleted.  To do housekeeping of stale weakrefs, it is sufficient to remove 
_one_ stale weakref for each class that is deleted.  It is not important that 
this is the correct stale weakref, all stale weakrefs are the same.

I've uploaded an updated patch with added in-line comments explaining the case.

--
Added file: http://bugs.python.org/file30253/subtype.patch

___
Python tracker 

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

[issue17934] Add a frame method to clear expensive details

[Guido van Rossum]

Guido van Rossum added the comment:

A downside of using this is that some extended traceback printers (such as 
cgitb.py in the stdlib, or and some things I've seen in web frameworks) won't 
be able to print the locals.  And pdb's pm() function would lose its value too. 
 So it'll remain a judgment call whether to use this.

As for Tulip, I think I've broken the cycle I was most concerned about, and 
I've also gotten rid of the lambda that cost me so much time debugging. :-)

--

___
Python tracker 

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

[issue17947] Code, test, and doc review for PEP-0435 Enum

[Phil Connell]

Changes by Phil Connell :


--
nosy: +isoschiz, pconnell

___
Python tracker 

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

[issue17969] multiprocessing crash on exit

[Kristján Valur Jónsson]

Kristján Valur Jónsson added the comment:

Well, knowing that they crash less in 3.3 doesn't really fix the problem now, 
does it?

We can consider two options then:
1) A multiprocessing specific fix.  Removing this handle close gil release 
(which is superfluous, since these calls aren't blocking in any real sense) 
will certainly remove _this_ instance of the crash.  An alternative is to make 
this worker thread non-daemon.  That shouldn't be too hard and shouldn't have 
any other side effects.

2) A general daemon thread fix.  For example, removing the GIL at the start of 
the shutdown process will make it impossible to release it.  We can do this by 
setting interpreter_lock to NULL.

I don't see the point of having 2.7 in bug fix mode if we can't fix bugs.

--

___
Python tracker 

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

[issue17950] Dynamic classes contain non-breakable reference cycles

[Daniel Urban]

Changes by Daniel Urban :


--
nosy: +daniel.urban

___
Python tracker 

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

[issue17934] Add a frame method to clear expensive details

[Antoine Pitrou]

Antoine Pitrou added the comment:

Updated patch addressing some of Nick's comments.

--
Added file: http://bugs.python.org/file30252/frame_clear_alt2.patch

___
Python tracker 

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

[issue17969] multiprocessing crash on exit

[Antoine Pitrou]

Antoine Pitrou added the comment:

Yes, I think it's too delicate to change in 2.7 right now. As Charles-François 
said, daemon threads should be much less crashy in 3.3.

--

___
Python tracker 

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

[issue17956] add ScheduledExecutor

[Antoine Pitrou]

Antoine Pitrou added the comment:

> > To be honest I can't find much to say about this proposal,
> 
> Hum, OK, I thought it would be a useful addition :-)

It's probably useful, but I'd have to take a closer look. It's been
a long time I haven't used separate threads for timers...

> Note that the time function must be "real" time, since the sleep are
> based on condition.wait() (otherwise if you just call an arbitrary
> sleep() function you can't be woken up when a new task with an
> earlier
> deadline is submitted).

Agreed, but at least tornado supports a custom time function, even
though their event loop is based on epoll() (under Linux):
http://www.tornadoweb.org/en/stable/ioloop.html#tornado.ioloop.IOLoop.time

This means:
1) the custom time function is used to adjust the epoll() timeout
according to pending timed calls
2) the epoll() call times out based on the system time function

I suppose it works well enough when the divergence is not too large,
and/or the wakeups are frequent enough that there are no glaring defects.

"Practicality beats purity", I guess :)

--

___
Python tracker 

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

[issue17969] multiprocessing crash on exit

[Charles-François Natali]

Charles-François Natali added the comment:

> Also, even though an IO call _can_ block, that doesn't mean that
> we _must_ release the gil for the duration.

Yes, otherwise some people will complain when the whole interpreter is stuck 
while a socket/NFS file handle/whatever is shutdown.

This problem isn't specific to multiprocessing: for example, if a daemon 
thread's thread state is cleared as part of the shutdown procedure, and one of 
the TLS object releases the GIL (e.g. a database connection), you'll have the 
same kind of problem.

AFAICT, it's "solved" in Python 3 because, as Richard said, you can't acquire 
the GIL once the interpreter is shutting down.
Daemon threads are *really* tricky, since they can wake-up while the 
interpreter is shutting down.
So they should be avoided as much as possible.
We can also try to think some more about a way to avoid/limit this type of 
issue, but it's not trivial...

--
nosy: +neologix, pitrou

___
Python tracker 

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

[issue17969] multiprocessing crash on exit

[Kristján Valur Jónsson]

Kristján Valur Jónsson added the comment:

I think that socket.close() is the exception rather than the rule here.  
What kind of handle is this?  It can't be a socket, since that would require 
closesocket.

Also, even though an IO call _can_ block, that doesn't mean that we _must_ 
release the gil for the duration.

I´m not very familiar with multiprocessing, I'm mainly trying to enhance 
robustness with our build tools here.  Would an alternative fix, making the 
worker thread a non-daemon, be hard to do?

--

___
Python tracker 

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

[issue17956] add ScheduledExecutor

[Charles-François Natali]

Charles-François Natali added the comment:

> To be honest I can't find much to say about this proposal,

Hum, OK, I thought it would be a useful addition :-)

> but I think it would be good if the time function were configurable (both for 
> test purposes, and to allow passing e.g. time.monotonic). I suppose this 
> could be an executor option.

Note that the time function must be "real" time, since the sleep are
based on condition.wait() (otherwise if you just call an arbitrary
sleep() function you can't be woken up when a new task with an earlier
deadline is submitted).
So it's different from the sched module, we can't really support
arbitrary time functions.

Note that I do think it would be a good idea to use time.monotonic()
when available (almost all modules have been updated, except the
future one). That's probably another issue, though.

--

___
Python tracker 

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

[issue17961] Use enum names as values in enum.Enum convenience API

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On May 13, 2013, at 02:24 PM, Nick Coghlan wrote:

>Yep. Since we no longer have a compelling reason for it to be anything
>else, it may as well be the human readable string.

Again, why does it matter?  That's the whole point of having a human readable
str() and repr().

--

___
Python tracker 

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

[issue17961] Use enum names as values in enum.Enum convenience API

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On May 13, 2013, at 02:06 PM, Antoine Pitrou wrote:

>Antoine Pitrou added the comment:
>
>> >I agree with Nick here, there's no reason to auto-number constants
>> >in
>> >Python. This is not C :-)
>> 
>> Why should they be strings?   Why not object()?
>
>Because strings are readable, I'd say.

The repr would then be



Yuck.

Also, you would have to allow for subclasses (e.g. IntEnum) to override
auto-assignment.  Clearly, you can't use strings for

X = IntEnum('X', 'start middle end')

--

___
Python tracker 

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

[issue17642] IDLE add font resizing hot keys

[Alejandro Rodas]

Alejandro Rodas added the comment:

I have merged the two patches: Now it queries the font size as I did in the 
original patch, and it also stores the position of the cursor based on Abhishek 
Kumar's modification of ZoomFont.py.

--
Added file: http://bugs.python.org/file30251/ZoomInOut.patch2

___
Python tracker 

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

[issue17961] Use enum names as values in enum.Enum convenience API

[Ethan Furman]

Ethan Furman added the comment:

So the repr will look like:



?

--

___
Python tracker 

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

[issue17969] multiprocessing crash on exit

[Richard Oudkerk]

Richard Oudkerk added the comment:

> In general, deallocators should have no side effects, I think.  
> Releaseing the GIL is certainly a side effect.

Notice that socket and file objects also release the GIL when being 
deallocated.  At least for sockets close() can block (e.g. if you you use the 
SO_LINGER option).

I am not sure whether we can ignore the possibility for connection objects.

> I realize that process shutdown is a delicate matter.  One delicate 
> thing is that we cannot allow worker threads to run anymore.  I see no 
> general mechanism for ensuring this, but surely at least not releasing 
> the GIL for deallocators is a first step?

I agree that shutdown matters are delicate, particularly when daemon threads 
are involved.  In fact I'm starting to agree with Antoine that daemon threads 
are evil and should be avoided wherever possible.

P.S. I think in Python 3.x this thread switching is stopped (by setting 
_Py_Finalizing to something non-NULL) before PyInterpreterState_Clear() is run.

--

___
Python tracker 

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

[issue17959] Alternate approach to aliasing for PEP 435

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On May 12, 2013, at 06:51 AM, Nick Coghlan wrote:

 class Shape(Enum):
>...   square = 2
>...   diamond = 1
>...   circle = 3
>...   alias_for_square = square

I see Guido pronounced against it, but I'm just registering that I kind of
like this.  You could probably have guess that since flufl.enum doesn't allow
aliases at all mostly because of the potential for accidental duplicate
values, which this would avoid.

Hmm.  LP: #1179529

--

___
Python tracker 

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

[issue17959] Alternate approach to aliasing for PEP 435

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue17961] Use enum names as values in enum.Enum convenience API

[Nick Coghlan]

Nick Coghlan added the comment:

On 14 May 2013 00:06, "Antoine Pitrou"  wrote:
>
>
> Antoine Pitrou added the comment:
>
> > >I agree with Nick here, there's no reason to auto-number constants
> > >in
> > >Python. This is not C :-)
> >
> > Why should they be strings?   Why not object()?
>
> Because strings are readable, I'd say.

Yep. Since we no longer have a compelling reason for it to be anything
else, it may as well be the human readable string.

--

___
Python tracker 

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

[issue17966] Lack of consistency in PEP 8 -- Style Guide for Python Code

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

It's not *particularly* silly[1], but I think that with Government backing, he 
could make it very silly.

[1] I mean, the right hand side isn't silly at all and the left hand side 
merely does a forward aerial half turn every alternative assignment.

--

___
Python tracker 

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

[issue17936] O(n**2) behaviour when adding/removing classes

[Antoine Pitrou]

Antoine Pitrou added the comment:

> I don't want guaranteed O(1) behaviour, just O(1) for the common case
> of creating a class, or a few classes, and then removing them.

Then just make sure you call remove_subclass() before PyObject_ClearWeakRefs()
in type_dealloc().

Really, this thing should be demonstrably correct. Performance of dynamic
class creation is not critical enough to take shortcuts.

--

___
Python tracker 

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

[issue17966] Lack of consistency in PEP 8 -- Style Guide for Python Code

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue17961] Use enum names as values in enum.Enum convenience API

[Antoine Pitrou]

Antoine Pitrou added the comment:

> >I agree with Nick here, there's no reason to auto-number constants
> >in
> >Python. This is not C :-)
> 
> Why should they be strings?   Why not object()?

Because strings are readable, I'd say.

--

___
Python tracker 

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

[issue17968] memory leak in listxattr()

[Benjamin Peterson]

Benjamin Peterson added the comment:

LGTM

--

___
Python tracker 

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

[issue17961] Use enum names as values in enum.Enum convenience API

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On May 13, 2013, at 10:10 AM, Antoine Pitrou wrote:

>I agree with Nick here, there's no reason to auto-number constants in
>Python. This is not C :-)

Why should they be strings?   Why not object()?

Why is `x.value == str(x)` a useful invariant to hold?

--

___
Python tracker 

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

[issue17970] Mutlithread XML parsing cause segfault

[mrDoctorWho0 .]

New submission from mrDoctorWho0 .:

Linux i386, Python 2.7.4. Multithread xml parsing via pyexpat cause 
segmentation fault

--
components: XML
files: pyexpat_crash_multithread.py
messages: 189131
nosy: mrDoctorWho0..
priority: normal
severity: normal
status: open
title: Mutlithread XML parsing cause segfault
versions: Python 2.7
Added file: http://bugs.python.org/file30250/pyexpat_crash_multithread.py

___
Python tracker 

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

[issue1772673] Replacing char* with const char*

[Eli Bendersky]

Eli Bendersky added the comment:

For external APIs visible to user code, this can cause some compatibility 
problems and users may need to at the very least re-compile this code. So -1 
here.

For new external APIs, having const wherever appropriate should be considered 
on a case by case basis.

For internal code this is a good idea, but I wouldn't go mass-slashing all the 
code base now replacing char* by const char*. Presenting some examples where 
this makes sense in particular would be interesting though. +0

--
nosy: +eli.bendersky

___
Python tracker 

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

[issue17966] Lack of consistency in PEP 8 -- Style Guide for Python Code

[Guido van Rossum]

Guido van Rossum added the comment:

This is a silly argument.

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

[issue17963] Deprecate the frame hack for implicitly getting module details

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue17950] Dynamic classes contain non-breakable reference cycles

[Nick Coghlan]

Changes by Nick Coghlan :


--
nosy: +ncoghlan

___
Python tracker 

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

[issue17962] Broken OpenSSL version in Windows builds

[Yogesh Chaudhari]

Yogesh Chaudhari added the comment:

@Antoine and @Georg:

You are right. There is nothing much to be done. The only difference is those 
of auto-generated files like Makefile and other config files created after 
running ./config script. 

This just needs a simple add/commit from the openssl site. It seems there is 
nothing else AFAICS

--

___
Python tracker 

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

[issue17968] memory leak in listxattr()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

LGTM

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue5803] email/quoprimime: encode and decode are very slow on large messages

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Here is a patch for 3.4 based on Matt's patch with additional optimizations. It 
speeds up body_encode() and header_encode().

$ ./python -m timeit -s "from email.quoprimime import body_encode as encode; x 
= open('Lib/decimal.py').read()[:10]"  "encode(x)"

Before patch: 1.12 sec per loop
After patch: 26.3 msec per loop

$ ./python -m timeit -s "from email.quoprimime import header_encode as encode; 
x = b'A'*100"  "encode(x)"

Before patch: 97.9 usec per loop
After patch: 23.7 usec per loop

For non-ascii data difference is even larger.

--
stage: needs patch -> patch review
Added file: http://bugs.python.org/file30249/email_quoprimime_fast_encode.patch

___
Python tracker 

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

[issue17950] Dynamic classes contain non-breakable reference cycles

[Fred L. Drake, Jr.]

Changes by Fred L. Drake, Jr. :


--
nosy: +fdrake

___
Python tracker 

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

[issue17962] Broken OpenSSL version in Windows builds

[Georg Brandl]

Georg Brandl added the comment:

I don't know what there is to do, so I can give no instructions.  It's best to 
let Martin handle it.

--

___
Python tracker 

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

[issue17950] Dynamic classes contain non-breakable reference cycles

[Martin Morrison]

Changes by Martin Morrison :


--
nosy: +isoschiz, pconnell

___
Python tracker 

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

[issue17936] O(n**2) behaviour when adding/removing classes

[Kristján Valur Jónsson]

Kristján Valur Jónsson added the comment:

Yes I am sure.  Please see the previous reasoning.  Igoring assigning to 
__bases__ for the moment...

Every class deletion will try to remove itself from the list.  Either it will 
a) find an existing reference in the weakref and remove it
b) find a None in the weakref and remove it.

b) is guaranteed to be the old weakref, because every previous class removal 
has also succeeded.  At any time, there is at most a single stale weakref in 
the list.

And _even_if_ there is a flaw in the argument, every call will remove _one_ 
stale (or just about to become stale) weakref from the list.  Whether it is its 
own weakref or that of a previous deletion is immaterial.  The removal of _one_ 
entry for each class deletion keeps the list at its optimal size.

For the case of assigning to __bases__, of course, the weakrefs are not stale 
and we must find the correct class to remove for correctness.

I don't want guaranteed O(1) behaviour, just O(1) for the common case of 
creating a class, or a few classes, and then removing them.

--

___
Python tracker 

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

[issue17969] multiprocessing crash on exit

[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

[issue17969] multiprocessing crash on exit

[Kristján Valur Jónsson]

New submission from Kristján Valur Jónsson:

We have observed this crash with some frequency when running our compilation 
scripts using multiprocessing.Pool()

By analysing the crashes, this is what is happening:
1) The Pool has a "daemon" thread managing the pool.
2) the worker is asleep, waiting for the GIL
3) The main thread exits.  The system starts its shutdown. During 
PyInterpreterState_Clear, it has cleared among other things the sys dict.  
During this, it clears an old traceback.  The traceback contains a 
multiprocessing.connection object.
4) The connection object is cleared.  It it contains this code:
Py_BEGIN_ALLOW_THREADS
CLOSE(self->handle);
Py_END_ALLOW_THREADS
5) The sleeping daemon thread is woken up and starts prancing around.  Upon 
calling sys.exc_clear() it crashes, since the tstate->interp->sysdict == NULL.


I have a workaround in place in our codebase:


static void
connection_dealloc(ConnectionObject* self)
{
if (self->weakreflist != NULL)
PyObject_ClearWeakRefs((PyObject*)self);

if (self->handle != INVALID_HANDLE_VALUE) {
/* CCP Change.  Cannot release threads here, because this
 * deallocation may be running during process shutdown, and
 * releaseing a daemon thread will cause a crash
Py_BEGIN_ALLOW_THREADS
CLOSE(self->handle);
Py_END_ALLOW_THREADS
 */
CLOSE(self->handle);
}
PyObject_Del(self);
}


In general, deallocators should have no side effects, I think.  Releaseing the 
GIL is certainly a side effect.

I realize that process shutdown is a delicate matter.  One delicate thing is 
that we cannot allow worker threads to run anymore.  I see no general mechanism 
for ensuring this, but surely at least not releasing the GIL for deallocators 
is a first step?

--
messages: 189123
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: multiprocessing crash on exit
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

[issue17936] O(n**2) behaviour when adding/removing classes

[Antoine Pitrou]

Antoine Pitrou added the comment:

> While I admit that I oversaw the exact requirement for __bases__, I think
> that allowing for a "None" to be sufficient when the class is being deleted 
> is an important improvement.

You can't be sure the "None" corresponds to the type being deleted and not 
another one. If you want guaranteed (almost :-)) O(1) behaviour, you must 
switch to a dict.

--

___
Python tracker 

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

[issue17936] O(n**2) behaviour when adding/removing classes

[Kristján Valur Jónsson]

Kristján Valur Jónsson added the comment:

Actually, in a program that dynamically creates a class, and then deletes it, 
you would expect a O(1) complexity.  adding children at the end, and searching 
from the end, is a way to achieve this.
While I admit that I oversaw the exact requirement for __bases__, I think that 
allowing for a "None" to be sufficient when the class is being deleted is an 
important improvement.  I realize that the therotetical worst case is O(n), but 
the practical common case is still O(1)

--

___
Python tracker 

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

[issue17936] O(n**2) behaviour when adding/removing classes

[Antoine Pitrou]

Antoine Pitrou added the comment:

> The second one is when the class is being deleted, for housekeeping
> of the weakrefs.
> I worry that your alternative will cause us to walk the entire list
> in the second case because it will be called when the weakref has
> been cleared, so  it will never find itself in the list, only None.

I don't think that matters much. In both cases the expected complexity
is O(n).

--

___
Python tracker 

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

[issue17936] O(n**2) behaviour when adding/removing classes

[Kristján Valur Jónsson]

Kristján Valur Jónsson added the comment:

There are two cases when remove_subclass is called:
One when we are changing base classes(the original use of this function), and 
in this case we must find the correct one.

The second one is when the class is being deleted, for housekeeping of the 
weakrefs.
I worry that your alternative will cause us to walk the entire list in the 
second case because it will be called when the weakref has been cleared, so  it 
will never find itself in the list, only None.  I'll make some tests to verify.

I think perhaps a small adjustment, an "exact" flag or something, can be added 
to differentiate between the two cases

--

___
Python tracker 

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

[issue17936] O(n**2) behaviour when adding/removing classes

[Antoine Pitrou]

Antoine Pitrou added the comment:

> In case this logic is flawed, we know that when remove_subclass() is
> called, exactly one child is removed.  Whether it is us, or some
> previous class, is irrelevant.

remove_subclass() is called when __bases__ is assigned to, so it is
not irrelevant:

>>> class A: pass
... 
>>> class B(A): pass
... 
>>> class C: pass
... 
>>> A.__subclasses__()
[]
>>> B.__bases__ = C,
>>> A.__subclasses__()
[]
>>> C.__subclasses__()
[]

--

___
Python tracker 

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

[issue17936] O(n**2) behaviour when adding/removing classes

[Kristján Valur Jónsson]

Kristján Valur Jónsson added the comment:

Basically the logic is this:  When the class goes away, it _always_ calls 
remove_subclass().  Now, this may be before or after the weakref has been clear 
so that it will either find itself in a weakref, or a clear weakref.

In case this logic is flawed, we know that when remove_subclass() is called, 
exactly one child is removed.  Whether it is us, or some previous class, is 
irrelevant.

--

___
Python tracker 

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

[issue17956] add ScheduledExecutor

[Antoine Pitrou]

Antoine Pitrou added the comment:

To be honest I can't find much to say about this proposal, but I think it would 
be good if the time function were configurable (both for test purposes, and to 
allow passing e.g. time.monotonic). I suppose this could be an executor option.

--

___
Python tracker 

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

[issue17961] Use enum names as values in enum.Enum convenience API

[Antoine Pitrou]

Antoine Pitrou added the comment:

I agree with Nick here, there's no reason to auto-number constants in Python. 
This is not C :-)

--
nosy: +pitrou

___
Python tracker 

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

[issue17966] Lack of consistency in PEP 8 -- Style Guide for Python Code

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +gvanrossum

___
Python tracker 

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

[issue17968] memory leak in listxattr()

[Antoine Pitrou]

New submission from Antoine Pitrou:

os.listxattr() leaks its internal buffer when the first call to C listxattr() 
fails with ERANGE. This wasn't caught by the refleak bot, probably because 
xattrs are not enabled on it.

--
files: listxattr_leak.patch
keywords: patch
messages: 189114
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: memory leak in listxattr()
type: resource usage
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30248/listxattr_leak.patch

___
Python tracker 

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

[issue17936] O(n**2) behaviour when adding/removing classes

[Antoine Pitrou]

Antoine Pitrou added the comment:

Attaching an alternative implementation for remove_subclass().

--
Added file: http://bugs.python.org/file30247/subtype2.patch

___
Python tracker 

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