[issue6006] ffi.c compile failures on AIX 5.3 with xlc

[Gilles PION]

Gilles PION  added the comment:

According to ffi site (http://sourceware.org/libffi/, the latest version is 
libffi-3.0.10, dated few days ago (which BTW I've been unable to compile on 
AIX, while 3.0.9 is OK)

So what are those 4.2.0-3 versions coming from?

--
nosy: +gpion

___
Python tracker 

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

[issue13014] Resource is not released before returning from the functiion

[Stefan Krah]

Stefan Krah  added the comment:

This doesn't look right to me: If (rdn != NULL) && (PyList_Size(rdn) > 0),
rdn is already decremented.

There is a leak though if  (rdn != NULL) && (PyList_Size(rdn) == 0).

--
nosy: +skrah

___
Python tracker 

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

[issue13014] _ssl.c: resource is not released before returning from the function

[Stefan Krah]

Changes by Stefan Krah :


--
title: Resource is not released before returning from the functiion -> _ssl.c: 
resource is not released before returning from the function

___
Python tracker 

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

[issue1172711] long long support for array module

[STINNER Victor]

STINNER Victor  added the comment:

> New changeset 672b63aff0f4 by Meador Inge in branch 'default'

Woops, I wrote the wrong module name. Thanks for fixing it.

--

___
Python tracker 

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

[issue12961] itertools: unlabelled balls in boxes

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Sorry Phillip, I'm closing this feature request because the benefits would 
likely be outweighed by the costs (maintenance, learning curve, module 
complexity, etc).  It was not the goal of the module to become a complete 
combinatorics toolkit; rather, the goal was to provide a set of practical tools 
for reasonably common needs (i.e. generating combinations of test case inputs).

You are invited to create a full-featured third-party combinatorics module and 
put it on PyPi. If the quality of the module is high, I will provide links to 
it from the itertools docs.  If the external module becomes popular 
(demonstrable user demand), I'll re-open this feature request for further 
discussion.

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

[issue8271] str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0

[Stefan Ring]

Changes by Stefan Ring :


--
nosy: +Ringding

___
Python tracker 

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

[issue12508] Codecs Anomaly

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

The final parameter is an extension to the decoder API signature,
so it's not surprising that not all codecs implement it.

The ones that do should use it for all calls, since that way
the actual consumed number of bytes is correctly reported
back to the StreamReader instance.

Note: The parameter name "final" is a bit misleading. What happens
is that the number of bytes consumed by the decoder were previously
always reported as len(buffer), since the C API for decoders did
not provide a way to report back the number of bytes consumed.
This was changed when stateful decoders were added to the C API,
since these do allow reporting back the consumed bytes. A more
appropriate name for the parameter would have been
"report_bytes_consumed".

--

___
Python tracker 

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

[issue12991] Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler

[Wong Wah Meng]

Wong Wah Meng  added the comment:

Good news is now I am still using ld, like what is generated in the Makefile 
file by configure script, and able to do the linking process for the built-in 
modules successfully. 

I only need to set CC="cc +DD64" and "CXX=aCC" and the process make process is 
able to build python executable 64-bit and all the built-in modules where the 
necessary bit can be found.

For other built-in modules, for example, _tkinter, I am also able to build it 
this time by setting these 3 environment variables where ~/local is where I 
installed my tcl/tk binary.

export CC="cc +DD64 -I/home/r32813/local/include"
export CXX=aCC
export LDFLAGS="-L/home/r32813/local/lib -lxnet"

I am finally able to build python 64-bit and built-in library on HP ia64 using 
HP compiler aCC. Thanks for the input everyone. :)

--

___
Python tracker 

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

[issue12991] Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler

[Wong Wah Meng]

Wong Wah Meng  added the comment:

Closing the issue. Please contact me if the README file for HP-UX Itanium 
64-bit build should be amended.

--
status: open -> closed

___
Python tracker 

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

[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug

[Zbyszek Szmek]

Changes by Zbyszek Szmek :


--
nosy: +zbysz

___
Python tracker 

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

[issue12508] Codecs Anomaly

[Ezio Melotti]

Ezio Melotti  added the comment:

AFAIU final means:
  * final=0: I'm passing in a few bytes, but there are more to come, so if the 
last byte(s) doesn't make sense on its own (e.g. it's a start byte but the 
continuation bytes are missing), wait for the others before raising an error;
  * final=1: these are the last bytes, so if the last byte(s) doesn't make 
sense raise an error (or ignore/replace) because there won't be other bytes 
that might turn that in a well-formed byte sequence.

--

___
Python tracker 

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

[issue12990] launcher can't work on path including tradition chinese char

[Teng Ricky]

Changes by Teng Ricky :


Added file: http://bugs.python.org/file23220/IMG_4359.JPG

___
Python tracker 

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

[issue12990] launcher can't work on path including tradition chinese char

[Ricky Teng]

Ricky Teng  added the comment:

Excuse me

This is my first time use this bug report.

I have uploaded a jpg to show what I do.

The result is that a console will show and nothing happen.

於 2011/9/16 下午 07:54, Ronald Oussoren 提到:
> New submission from Ronald Oussoren:
>
> Could you please add some more information on how I can reproduce this issue?
>
> --
> stage:  ->  test needed
> type:  ->  behavior
>
> ___
> Python tracker
> 
> ___
>

--
title: launcher can't work on path including tradition chinese char -> launcher 
can't work on path including tradition chinese  char

___
Python tracker 

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

[issue13019] bytearrayobject.c: Resource is not released before returning from the functiion

[Mark Dickinson]

Changes by Mark Dickinson :


--
components: +Interpreter Core
title: Resource is not released before returning from the functiion -> 
bytearrayobject.c: Resource is not released before returning from the functiion

___
Python tracker 

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

[issue11682] PEP 380 reference implementation for 3.3

[Éric Araujo]

Éric Araujo  added the comment:

Doc patch 002 is not strictly related to PEP 380 but pertains more to #10289.

--

___
Python tracker 

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

[issue6006] ffi.c compile failures on AIX 5.3 with xlc

[rubisher]

rubisher  added the comment:

Hello Gilles,

The libffi-4.2.0-3 I used, was coming from the previously mentioned repository:
.

That said, if I click on  link, it points me to 

So, as far as I understand, it's the version of libffi coming with gcc project 
and so of the same release as the gcc 
available at this place i.e. 4.2.0-3.

What's the difference with sourceware.org/libffi?
It's very not clear to me: reading this announce: 
, it seems 
that gcc one is the merge of the upstream?

Hth,
r.

PS: As I was fired from my previous position, I don't have any more access to 
my testing system and so couldn't more 
helpful, sorry :<(

On 09/21/2011 09:07 AM, Gilles PION wrote:
>
> Gilles PION  added the comment:
>
> According to ffi site (http://sourceware.org/libffi/, the latest version is 
> libffi-3.0.10, dated few days ago (which BTW I've been unable to compile on 
> AIX, while 3.0.9 is OK)
>
> So what are those 4.2.0-3 versions coming from?
>
> --
> nosy: +gpion
>
> ___
> Python tracker
> 
> ___
>

--

___
Python tracker 

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

[issue828450] sdist generates bad MANIFEST on Windows

[higery]

higery  added the comment:

>>I’ve just found another problem with MANIFEST files created in Windows: they 
>>use CRLF.

One cann't let Python generate MANIFEST files taking Unix-style LF as newline 
endings On Windows, I think.

So, does it mean even though we have already made much effort for this bug, it 
still cann't make MANIFEST file on different platforms cross-platform?

--

___
Python tracker 

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

[issue828450] sdist generates bad MANIFEST on Windows

[Éric Araujo]

Éric Araujo  added the comment:

> One cann't let Python generate MANIFEST files taking Unix-style LF as newline
> endings On Windows, I think.
Why?  Python can open it fine, and it’s not meant for human edition, so the 
stupidity of notepad.exe is not a problem .

> So, does it mean even though we have already made much effort for this bug, it
> still cann't make MANIFEST file on different platforms cross-platform?
The problem is that the docs never say that MANIFEST is cross-platform, so I’m 
not sure changing this qualify for a bug fix.  I have to find time to ask 
distutils-sig.

See also my point 1) in my previous message: the tests don’t test anything on 
non-Windows.

For d2 however we can change the MANIFEST format as we like.

--

___
Python tracker 

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

[issue12944] Accept arbitrary files for packaging's upload command

[Éric Araujo]

Éric Araujo  added the comment:

This was discussed some time ago in a thread starting here: 
http://mail.python.org/pipermail/catalog-sig/2011-May/003736.html  I’ll 
summarize the important parts below.

Currently, upload will only push files that are products of a command run from 
the same command line, e.g. “sdist upload”.
If you run “sdist”, check the result, and then do “sdist upload”, the second 
sdist should be exactly the same, unless your setup.py is buggy, you made 
changes to your files or you have a computer problem.  (I agree that’s a lot of 
unless).  So for distutils, having to run “sdist upload” is not inefficient, 
and makes you be explicit about the files you want to push, which is IMO good.

A trick can be used to avoid the second sdist to redo all its work: Fist you 
run “python setup.py sdist --keep-temp”, then you check the sdist, and to 
upload you call “python setup.py sdist --dry-run upload”.  I’m not in favor of 
adding that trick to the doc, as for normal usage, running sdist twice is okay.

As you may not be aware, distutils is under a feature freeze.  To cut a long 
story short, let’s just say that it’s impossible to gradually improve it 
without breaking a lot of third-party code, so we only fix bugs and we add 
features in distutils2, the next gen (included in Python 3.3 and available on 
PyPI for 2.4-3.2 soon).

I think there are good arguments to improve upload for distutils2, mainly:
- you never know what can go wrong, so you want to upload files you have tested
- PyPI will reject bad files anyway, no sense in being more restrictive on the 
client side

I propose a new option, say -f/--file, that takes a filename as argument:

  pysetup run upload -f dist/spam-0.2.tar.gz -f dist/spam-0.2.exe

I’d prefer to avoid globs (upload -i 'dist.spam-0.1.*' e.g.) because I want to 
retain the original design choice of the upload command: the person doing the 
upload needs to be explicit about what kind of file for what versions and with 
what Python version to upload.

Does that sounds good?

--
assignee: tarek -> eric.araujo
components: +Distutils2 -Distutils
nosy: +alexis
title: setup.py upload to pypi needs to work with specified files -> Accept 
arbitrary files for packaging's upload command
versions: +3rd party, Python 3.3

___
Python tracker 

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

[issue12981] rewrite multiprocessing (senfd|recvfd) in Python

[Roundup Robot]

Roundup Robot  added the comment:

New changeset c158eac8e951 by Charles-François Natali in branch '2.7':
Issue #12981: test_multiprocessing: catch ImportError when importing
http://hg.python.org/cpython/rev/c158eac8e951

New changeset 6e04d406bb86 by Charles-François Natali in branch '3.2':
Issue #12981: test_multiprocessing: catch ImportError when importing
http://hg.python.org/cpython/rev/6e04d406bb86

New changeset 21b837aa07b9 by Charles-François Natali in branch 'default':
Issue #12981: test_multiprocessing: catch ImportError when importing
http://hg.python.org/cpython/rev/21b837aa07b9

--

___
Python tracker 

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

[issue13002] peephole.c: unused parameter

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 573d73e62bbc by Stefan Krah in branch 'default':
Issue #13002: Fix Visual Studio warning (not enough actual parameters).
http://hg.python.org/cpython/rev/573d73e62bbc

--
nosy: +python-dev

___
Python tracker 

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

[issue12991] Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Wah Meng and I were discussing about this in a separate thread as well.
I think, it is a good idea to improve the Readme for this issue.

Wah Meng,  since you already went at length to contact HP and clarify linker 
issue with 64 bit and found a solution to it, it would be a good idea to 
document it.

Is this the only change for the successful compilation - CC="cc +DD64" and 
CXX="aCC" .

If there are more details, you can provide changes to the Readme in the form a 
diff and I shall commit to the trunk.

Thanks!

--
assignee:  -> orsenthil
components: +Documentation -Build
nosy: +orsenthil
resolution: works for me -> 
status: closed -> open
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

[issue12991] Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler

[Stefan Krah]

Stefan Krah  added the comment:

> I think, it is a good idea to improve the Readme for this issue.

+1.

Wah Meng: Building everything is not enough, does 'make test'
complete successfully?

For gcc, Python2.7 relies on two critical options, -fno-strict-aliasing
and -fwrapv. The HP compiler might need similar options.

--

___
Python tracker 

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

[issue12991] Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Wah meng - Instructions to get the _tkinter compile would be a good idea too.  
Also, can you verify the same instructions would work for 3.2 version of Python?

--
keywords: +patch
Added file: http://bugs.python.org/file23221/README.patch

___
Python tracker 

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

[issue13005] operator module docs include repeat

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 0d0bfbaaf95c by Senthil Kumaran in branch '3.2':
Fix closes issue13005 - Remove the mention of 'repeat' method in the operator 
module documentation.
http://hg.python.org/cpython/rev/0d0bfbaaf95c

New changeset 6c60f2aacc83 by Senthil Kumaran in branch 'default':
merge 3.2.  Fix closes issue13005 - Remove the mention of 'repeat' method in 
the operator module documentation.
http://hg.python.org/cpython/rev/6c60f2aacc83

--
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> 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

[issue13020] structseq.c: refleak

[Stefan Krah]

Changes by Stefan Krah :


--
title: Resource is not released before returning from the functiion -> 
structseq.c: refleak

___
Python tracker 

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

[issue13013] _ctypes.c: refleak

[Stefan Krah]

Changes by Stefan Krah :


--
title: Resource is not released before returning from the functiion -> 
_ctypes.c: refleak

___
Python tracker 

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

[issue13017] pyexpat.c: refleak

[Stefan Krah]

Changes by Stefan Krah :


--
title: Resource is not released before returning from the functiion -> 
pyexpat.c: refleak

___
Python tracker 

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

[issue13018] dictobject.c: refleak

[Stefan Krah]

Changes by Stefan Krah :


--
title: Resource is not released before returning from the functiion -> 
dictobject.c: refleak

___
Python tracker 

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

[issue13017] pyexpat.c: refleak

[Stefan Krah]

Changes by Stefan Krah :


--
components: +Extension Modules
stage:  -> patch review
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

[issue13018] dictobject.c: refleak

[Stefan Krah]

Changes by Stefan Krah :


--
components: +Interpreter Core
stage:  -> patch review
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

[issue13014] _ssl.c: refleak

[Stefan Krah]

Changes by Stefan Krah :


--
components: +Extension Modules
title: _ssl.c: resource is not released before returning from the function -> 
_ssl.c: refleak
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

[issue13016] selectmodule.c: refleak

[Stefan Krah]

Changes by Stefan Krah :


--
components: +Extension Modules
stage:  -> patch review
title: Resource is not released before returning from the functiion -> 
selectmodule.c: refleak
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

[issue13015] _collectionsmodule.c: refleak

[Stefan Krah]

Changes by Stefan Krah :


--
components: +Extension Modules
stage:  -> patch review
title: Resource is not released before returning from the functiion -> 
_collectionsmodule.c: refleak
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

[issue13019] bytearrayobject.c: refleak

[Stefan Krah]

Changes by Stefan Krah :


--
title: bytearrayobject.c: Resource is not released before returning from the 
functiion -> bytearrayobject.c: refleak

___
Python tracker 

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

[issue13002] peephole.c: unused parameter

[Stefan Krah]

Stefan Krah  added the comment:

Thanks for checking the patch! Closing this 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

[issue6549] ttk.Style not translating some Tcl options

[Ethan Furman]

Ethan Furman  added the comment:

Not sure what 'embossed' has to do with not having dashes as part of the 
element option names.

Attached is a patch (hopefully in the right format) agains the current 3.3 
sources to remove the dash from the names in .element_names(), as well as 
return None from .configure() when setting options.

--
keywords: +patch
nosy: +stoneleaf
Added file: http://bugs.python.org/file23222/ttk.patch

___
Python tracker 

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

[issue13010] devguide doc: ./python.exe on OS X

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 9363db42626a by Ezio Melotti in branch 'default':
#13010: explain why the python executable has an .exe extension on OS X.
http://hg.python.org/devguide/rev/9363db42626a

--
nosy: +python-dev

___
Python tracker 

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

[issue13010] devguide doc: ./python.exe on OS X

[Ezio Melotti]

Ezio Melotti  added the comment:

Fixed, thanks for the report and the suggestion!

--
components: +Devguide -Documentation
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

[issue13010] devguide doc: ./python.exe on OS X

[Ezio Melotti]

Changes by Ezio Melotti :


--
assignee: docs@python -> ezio.melotti

___
Python tracker 

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

[issue13026] Dis module - documentation of MAKE_FUNCTION

[Arnaud Delobelle]

New submission from Arnaud Delobelle :

The description of the opcode MAKE_FUNCTION in the dis module document is out 
of date.  It still describes the 2.X version of the opcode:

"""
MAKE_FUNCTION(argc)
Pushes a new function object on the stack. TOS is the code associated with the 
function. The function object is defined to have argc default parameters, which 
are found below TOS.
"""

According to http://hg.python.org/cpython/file/default/Python/ceval.c#l2684:


 2684 int posdefaults = oparg & 0xff;
 2685 int kwdefaults = (oparg>>8) & 0xff;
 2686 int num_annotations = (oparg >> 16) & 0x7fff;

So the documentation should read something like

"""
MAKE_FUNCTION(argc)
Pushes a new function object on the stack. TOS is the code associated with the 
function. The function object is defined to have argc & 0xFF positional default 
parameters, (argc >> 8) & 0xFF keyword only default parameters, and (argc >> 
16) & 0x7FFF parameter annotations which are push below TOS in this order. For 
each keyword only default, the name of the parameter is pushed just below its 
default value. On top of all the annotations, a tuple is pushed listing the 
parameter names for these annotations.
"""

--
assignee: docs@python
components: Documentation
messages: 144393
nosy: arno, docs@python, terry.reedy
priority: normal
severity: normal
status: open
title: Dis module - documentation of MAKE_FUNCTION
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

[issue13026] Dis module - documentation of MAKE_FUNCTION

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Minor edit: in 'which are push below TOS', /push/pushed/.
I understand 'in this order' to mean that positional defaults are pushed first 
so that they end up on the bottom, whereas annotations are pushed last and end 
up just under the code object. Correct? (This order makes sense given the 
structure of function headers.)

--

___
Python tracker 

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

[issue13026] Dis module - documentation of MAKE_FUNCTION

[Arnaud Delobelle]

Arnaud Delobelle  added the comment:

Yes, you are correct.  Reading this again, I don't think I should have used the 
word "pushed" as it sounds like the effect of the opcode is to push stuff onto 
the stack, whereas I was only trying to describe what is on the stack just 
before the opcode is executed.

--

___
Python tracker 

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

[issue6549] ttk.Style not translating some Tcl options

[Ethan Furman]

Ethan Furman  added the comment:

The changes to Style.configure were not good.  Corrected so the (possibly 
empty) result is returned when a query is made but not when configuration is 
set.

Two patches: one for the element_names issue, one for the configure issue.

Question:  Does it ever make sense to do both a query and a configuration 
update in the same call?  I don't think it is:

--> ttk.Style.configure('TButton', 'relief', relief='sunken'
'raised'
--> s.configure('TButton','relief')
'raised'

Does it make sense to raise an exception in configure if both query_opt and kw 
specified?

--
Added file: http://bugs.python.org/file23223/ttk_style_fixes.zip

___
Python tracker 

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

[issue6549] ttk.Style -- minor issues with element_names and configure

[Ethan Furman]

Changes by Ethan Furman :


--
title: ttk.Style not translating some Tcl options -> ttk.Style -- minor issues 
with element_names and configure

___
Python tracker 

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

[issue13013] _ctypes.c: refleak

[Meador Inge]

Meador Inge  added the comment:

This patch seems reasonable.  Upon looking at the code in more
detail, however, I can't see how the error condition that leaks the
reference can ever by triggered.  In particular, the following code
from the 'PyCArrayType_from_ctype' function:

if (!PyType_Check(itemtype)) {
PyErr_SetString(PyExc_TypeError,
"Expected a type object");
return NULL;
}

'PyCArrayType_from_ctype' is only called from 'CDataType_repeat'.  The
'CDataType_repeat' function is only used to implement the 'sq_repeat' 
slot in 'CDataType_as_sequence'.  'CDataType_as_sequence' is used in all 
of the implemented ctypes (struct, array, union, simple, ...).

Unless 'PyCArrayType_from_ctype' is called through some other means
(it is public), then 'itemtype' should *always* be a type.  Or am 
I missing something obvious?  So, we could add the decref or just remove 
the type check code all together (and make 'PyCArrayType_from_ctype'
private).

--
nosy: +amaury.forgeotdarc, belopolsky

___
Python tracker 

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

[issue13020] structseq.c: refleak

[Meador Inge]

Meador Inge  added the comment:

In general I agree that a test case is needed, but in this particular
case its looks to be non-trivial to come up with one.  The only way
the reference leak is triggered is when memory is exhausted during an
attempt to new up a 'PyStructSequence' object.

--
nosy: +meador.inge

___
Python tracker 

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

[issue12881] ctypes: segfault with large structure field names

[Meador Inge]

Meador Inge  added the comment:

I am going to open separate issues for the other crashers.

> Also, PyUnicode_FromFormat could be used instead of sprintf.

Amaury, how so?  'sprintf' and 'stgdict->format' work with 'char *'s 
where as 'PyUnicode_FromFormat' builds a unicode string object.

Unless there are any objections, I am going to commit as is.

--

___
Python tracker 

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

[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis

[Meador Inge]

Meador Inge  added the comment:

I took a quick look over the final patch (I will do a more thorough
review later).  I like the general idea a lot.  The first thing that
popped out at me are the names 'OpInfo' and 'get_opinfo'.

'OpInfo' makes it sound like information concerning only the opcode, but
these objects really represent bytecode instructions.  I see a lot
of code in the future like:

for opinfo in dis.get_opinfo(thing):
process(opinfo)

which seems vague.  The following seems clearer to me:

for instr in dis.bytecode_instructions(thing):
process(instr)

And instead of 'OpInfo' perhaps 'ByteCodeInstruction'.  Even the current
'dis' documentation uses the terminology "Byte Code Instruction".

--
nosy: +meador.inge

___
Python tracker 

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

[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis

[Nick Coghlan]

Nick Coghlan  added the comment:

'Op' is just an abbreviation of 'operation'. So 'operation code' becomes 
'opcode' and 'operation information' becomes 'opinfo'. The fact that it comes 
for the 'dis' module gives the context that the *kind* of operation we're 
talking about is a Python byte code instruction.

When people are hacking on bytecode in the future, they'll likely end up using 
get_opinfo() a fair bit, so swapping the succinct 'opinfo' for the verbose 
'bytecode_instruction' strikes me as a poor trade-off.

--

___
Python tracker 

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