[issue10461] Use with statement throughout the docs

[Vinay Sajip]

Vinay Sajip  added the comment:

I've already made the change, Terry, just holding off committing it because 
Georg has frozen the py3k branch until 3.2b2 is released.

There are a few other changes I'm making, will commit these soon after 3.2b2 is 
released.

--

___
Python tracker 

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

[issue4761] create Python wrappers for openat() and others

[Matt Joiner]

Changes by Matt Joiner :


--
nosy: +anacrolix

___
Python tracker 

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

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

[STINNER Victor]

STINNER Victor  added the comment:

Le lundi 20 décembre 2010 07:55:08, vous avez écrit :
> +#define NFAULT_SIGNALS (sizeof(fault_signals) / sizeof(fault_signals[0]))
> +static fault_handler_t fault_handlers[4];
> 
> , should use "NFAULT_SIGNALS" instead of "4".

Ah yes, NFAULT_SIGNALS is a better choice than the maximum of possible signals 
(4).

> However, this bit of code bothers me a lot:
> 
> +const int fd = 2; /* should be fileno(stderr) */
> 
> To assume that fd=2 is the write place to be writing bytes is assuming
> quite a bit about the state of the application. It is not unusual at all
> to close 0,1,2 when writing daemons, which frees them up to be assigned to
> *anything*.

Write into a closed file descriptor just does nothing. Closed file descriptors 
are not a problem.

> For all you know, fd=2 currently is a network socket that you
> will be throwing gibberish at, or worse it could be a block device that
> you are writing gibberish on.

The GNU libc has also a fault handler (source code: debug/segfault.c). It uses 
the file descriptor 2, except if SEGFAULT_OUTPUT_NAME environment variable is 
set (value stored in "fname" variable): open the specified file.

  /* This is the name of the file we are writing to.  If none is given
 or we cannot write to this file write to stderr.  */
  fd = 2;
  if (fname != NULL)
{
  fd = open (fname, O_TRUNC | O_WRONLY | O_CREAT, 0666);
  if (fd == -1)
fd = 2;
}

The GNU libc installs handlers for SIGSEGV, SIGILL, SIGBUS, SIGSTKFLT, 
SIGABBRT and SIGFPE signals. The handler restores the default handler and re-
raise the signal:

  /* Pass on the signal (so that a core file is produced).  */
  sa.sa_handler = SIG_DFL;
  sigemptyset (&sa.sa_mask);
  sa.sa_flags = 0;
  sigaction (signal, &sa, NULL);
  raise (signal);

Where "raise(signal);" is something like kill(getpid(), signal).

It only uses an alternate stack if SEGFAULT_USE_ALTSTACK environment variable 
is set.

The handler can display registers, the backtrace and the memory mappings, 
depending on the compilation options and the operating system.

> The closest discussion I could find on this subject was on the libstdc++
> mailing-list with regard to their verbose termination code:
> 
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02388.html
> 
> AFAICT, their conclusion was that the only reasonable solution was to write
> to the stderr FILE since it was the only thing that is guaranteed to make
> sense always (even though it may fail). Their situation is different in
> that they are handling a C++ exception, so they don't have to stick to
> async-safe functions, but absent that extra difficulty, I believe the
> reasoning is the same.

The FILE* type cannot be used because fprintf(), fputs(), ... are not signal-
safe.

> I'm not sure there is a safe way to know what the fileno for "sys.stderr"
> is because it can be anything, including an object whose fileno changes
> over time

The signal handler cannot access the Python object. Eg. if sys.stderr is a 
StringIO() (which has no file descriptor), it cannot be used.

> However, I think it would be fair to support only built-in io
> types that are obviously safe, since you could cache the fileno() value at
> assignment to use in your fault handler.

The problem is to detect that stderr file descriptor changes (eg. closed, 
duplicated, reopened, etc.). I don't think that it's possible to detect such 
changes (with a portable function).

--

___
Python tracker 

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

[issue10739] Subprocess behavior on Windows

[R. David Murray]

R. David Murray  added the comment:

This might be an example of the general problem that on windows, sockets and 
files don't mix well.  You can't use a file in a select call, either.

I think there are two possibilities here: either makefile doesn't produce 
anything very useful on windows, or there's a bug in either makefile or 
subprocess.  If the former, the proper place to document it would be in the 
makefile docs.

--
assignee: d...@python -> 
nosy: +brian.curtin, gregory.p.smith, r.david.murray, tim.golden
versions: +Python 3.1

___
Python tracker 

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

[issue10694] zipfile.py end of central directory detection not robust

[Kevin Hendricks]

Kevin Hendricks  added the comment:

I have not looked at how other tools handle this.  They could simply ignore 
what comes after a valid endrecdata is found, they could strip it out (truncate 
it) or make it into a final comment.  I guess for simply unpacking a zip 
archive, all of these are equivalent (it goes unused).

But if you are copying a zip archive to another archive then ignoring it and 
truncating it may be safer in some sense (since you have no idea what this 
extra data is for and why it might be attached) but then you are not being 
faithful to the original but at the same time you do not want to create 
improper zip archives.  If you change the extra data into a final comment, then 
at least none of the original data is actually lost (just moved slightly in the 
copied zip and protected as a comment) and could be recovered if it turns out 
to have been useful.  With so many things using/making the zip archive format 
(jars, normal zips, epubs, etc) you never know what might have been left over 
at the end of the zip file and if it was important.

So I am not really sure how to deal with this properly.  Also I know nothing 
about _EndRecData64 and if it needs to somehow be handled in a different way.

So someone who is very familiar with the code should look at this and tell us 
what is the right thing to do and even if the approach I took is correct (it 
works fine for me and I have taken to including my own zipfile.py in my own 
projects until this gets worked out) but it might not be the right thing to do.

As for a test case, I know nothing about that but will look at test_zipfile.py. 
 I am a Mac OS X user/developer so all of my code is targeted to running on 
both Python 2.5 (Mac OS X 10.5.X) and Python 2.6 (Mac OS 10.6.X). Python 3.X 
and even Python 2.7 are not on my horizon and not even on my build machine 
(trying to get Mac OS X users to install either would be an experience in 
frustration). I simply looked at the source in Python 2.7 and Python 3.1.3 
(from the official Python releases from python.org) to see that the problem 
still exists (and it does).

--

___
Python tracker 

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

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

[STINNER Victor]

STINNER Victor  added the comment:

The fault handler is unable to retrieve the thread state if the GIL is 
released. I will try to fix that.

--

___
Python tracker 

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

[issue10739] Subprocess behavior on Windows

[Ross Lagerwall]

Ross Lagerwall  added the comment:

Since the code in subprocess gets the underlying fileno of the file-like object 
(line 819 of subprocess.py), I presume it is an example of the general problem 
of files and sockets not mixing very well on Windows.

So, I have attached a patch to document this in socket.makefile().

However, I also see that *it* is documented in select.select() that it will not 
work with Windows file-like objects. Maybe there should still be a note in 
subprocess.Popen() as per the first patch?

--
Added file: http://bugs.python.org/file20117/socketdoc.diff

___
Python tracker 

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

[issue10694] zipfile.py end of central directory detection not robust

[R. David Murray]

R. David Murray  added the comment:

It's pretty easy, really, to do an SVN checkout of python and compile it on a 
mac, if you are at all familiar with the unix command line.  If you don't have 
the time or desire for that, though, someone will eventually get to it, we just 
don't know when ;)

--

___
Python tracker 

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

[issue10694] zipfile.py end of central directory detection not robust

[Kevin Hendricks]

Kevin Hendricks  added the comment:

Been programming on unix/vax and then linux since the mid 80s and on punch 
cards in the late 70s.  Grew my first beard writing 8080 and Z80 assembler.  
All of that was over 30 years ago. 

All I want to do is report a damn bug!

Then I get nudged for a test case (although how to recreate the bug was already 
described) so I add the two lines to create a test case.  

Then I get nudged for a patch, so I give a patch even though there are many 
ways to deal with the issue.

Then I get nudged for patches for other branches, then I get nudged for 
official test_zipfile.py patches.

All of this **before** the damn owner has even bothered to look at it and say 
if he/she even wants it or if the patch is even correct.

I have my own working code for the epub ebook stuff I am working on so this 
issue no longer impacts me.

How did I go from a simple bug report to having to build python's latest 
checkout just to get someone to look at the bug.

You have got to be kidding me!

I am done here,  do what you want with the bug.

--

___
Python tracker 

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

[issue10087] HTML calendar is broken

[Ron Adam]

Changes by Ron Adam :


--
nosy: +ron_adam

___
Python tracker 

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

[issue10740] sqlite3 module should allow DDL statements in transactions

[Scott Urban]

New submission from Scott Urban :

The python sqlite module automatically commits open transactions
when it encounters a DDL statement.  This is unnecessary; DDL is
transactional in my testing (see attached).

Attached patch addresses the issue. Patch is against 2.6.1, but
looking at Trunk in svn, it seems like the patch is needed and
would apply. One issue I could foresee is that this behavior might
depend on the sqlite version in use (I'm on 3.6.10).

Patch also allows pragma statement.

--
components: Library (Lib)
files: pysql-transactions.2.diff
keywords: patch
messages: 124392
nosy: scott.urban
priority: normal
severity: normal
status: open
title: sqlite3 module should allow DDL statements in transactions
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file20118/pysql-transactions.2.diff

___
Python tracker 

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

[issue10740] sqlite3 module should allow DDL statements in transactions

[Scott Urban]

Scott Urban  added the comment:

Here are some tests.

--
Added file: http://bugs.python.org/file20119/test_sqlite_ddl.py

___
Python tracker 

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

[issue10741] PyGILState_GetThisThreadState() lacks a doc entry

[Antoine Pitrou]

New submission from Antoine Pitrou :

PyGILState_GetThisThreadState() is "documented" in Include/pystate.h but not in 
the official docs. It should be documented along PyGILState_Ensure() and 
friends.

--
assignee: d...@python
components: Documentation
messages: 124394
nosy: d...@python, haypo, pitrou
priority: normal
severity: normal
status: open
title: PyGILState_GetThisThreadState() lacks a doc entry
versions: Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue10739] Subprocess behavior on Windows

[R. David Murray]

R. David Murray  added the comment:

I think I'll leave that decision up to the doc crew.  My thought was that 
makefile was supposedly returning a file, therefore it was appropriate to 
document there that it wasn't really a file on windows, whereas subprocess docs 
are only talking about files, and it only just so happens that you can pass it 
a socket on unix by using makefile.

--
assignee:  -> d...@python
stage:  -> patch review

___
Python tracker 

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

[issue10694] zipfile.py end of central directory detection not robust

[R. David Murray]

R. David Murray  added the comment:

Sorry, I thought I was being clear that if you *wanted* to help further here 
was how you could, but if you didn't then we'd get to it eventually.  We're all 
volunteers here, just like you, so every bit of help...helps, and we thank you 
sincerely for taking the time to report the bug and provide the preliminary 
patch and test.

--

___
Python tracker 

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

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

[Scott Dial]

Scott Dial  added the comment:

On 12/20/2010 8:30 AM, STINNER Victor wrote:
> Write into a closed file descriptor just does nothing. Closed file 
> descriptors 
> are not a problem.

My issue not with a closed file descriptor, it is with an open file
descriptor that is not what you think it is.

>> For all you know, fd=2 currently is a network socket that you
>> will be throwing gibberish at, or worse it could be a block device that
>> you are writing gibberish on.
> 
> The GNU libc has also a fault handler (source code: debug/segfault.c). It 
> uses 
> the file descriptor 2, except if SEGFAULT_OUTPUT_NAME environment variable is 
> set (value stored in "fname" variable): open the specified file.

The GNU libc segfault handler is *opt-in* via the SEGFAULT_SIGNALS
environment variable. I do not know of a system where SEGFAULT_SIGNALS
is a part of the default environment. I suspect the only time anyone
uses that variable and code is if they are using the "catchsegv" tool,
which comes with glibc. In any case, that developer should be aware of
the implication of closing fd 2.

> The FILE* type cannot be used because fprintf(), fputs(), ... are not signal-
> safe.

My point was that in C++, they have an object that an application
developer more readily associates with "stderr" than fd 2. That writing
to "stderr" leads to a write to fd 2 is incidental, because it's
possible that "stderr" does *not* lead to a write to fd 2 and that
writing to fd 2 would be a bad thing to do blindly. For instance, you
can call freopen(path, mode, stderr) and fd 2 will end up closed and
another fd will be the target of stderr. I don't believe POSIX
guarantees that open() will not re-use fd 2.

> The problem is to detect that stderr file descriptor changes (eg. closed, 
> duplicated, reopened, etc.). I don't think that it's possible to detect such 
> changes (with a portable function).

When I said that, I hadn't fully investigated the intricacies of the io
types. I was unaware that you could assign to "sys.stderr.buffer.raw"
and change out the target fd. I assumed a BufferedWriter could not have
the target stream changed out from beneath it. So, I don't have a
solution to the problem of knowing the correct (if any) file descriptor
to write to.

If the argument is made that fd 2 is the right place for most Python
applications, then there needs to be a programmatic way to disable this
feature and/or tell it where to write, so that programs that daemonize
can do the right thing.

--
title: Display Python backtrace on SIGSEGV, SIGFPE and fatal error -> Display 
Python backtrace on SIGSEGV,  SIGFPE and fatal error

___
Python tracker 

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

[issue10740] sqlite3 module should allow DDL statements in transactions

[R. David Murray]

R. David Murray  added the comment:

See also Issue 8145.  It would be nice if someone could sort all this out, but 
I'm not knowledgeable enough to do so.

For this patch, it would be a significant change it behaviour.  Therefore it 
would have to be a new feature controlled by a flag of some sort (which is part 
of the reason for the reference to issue 8145).

--
nosy: +ghaering, r.david.murray
type: behavior -> feature request
versions: +Python 3.3 -Python 2.6

___
Python tracker 

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

[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> > The problem is to detect that stderr file descriptor changes (eg. closed, 
> > duplicated, reopened, etc.). I don't think that it's possible to detect 
> > such 
> > changes (with a portable function).
> 
> When I said that, I hadn't fully investigated the intricacies of the io
> types. I was unaware that you could assign to "sys.stderr.buffer.raw"
> and change out the target fd. I assumed a BufferedWriter could not have
> the target stream changed out from beneath it.

AFAICT, this is not deliberate (not documented, and not tested for). It
should probably be fixed, actually, because there's no code that I know
of that ensures it does something meaningful.

--
title: Display Python backtrace on SIGSEGV, SIGFPE and fatal error -> 
Display Python backtrace on SIGSEGV, SIGFPE and fatal error

___
Python tracker 

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

[issue10557] Malformed error message from float()

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
versions: +Python 3.1

___
Python tracker 

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

[issue10715] uninformative error message

[Éric Araujo]

Changes by Éric Araujo :


--
components: +IO
nosy: +eric.araujo
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

___
Python tracker 

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

[issue10728] argparse.ArgumentParser.print_help uses sys.stdout

[Éric Araujo]

Éric Araujo  added the comment:

Alright, I didn’t know you were doing mass merges.  I personally prefer to 
leave reports open until backported, now I’ll know your habits.

--

___
Python tracker 

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

[issue8145] Documentation about sqlite3 isolation_level

[Éric Araujo]

Changes by Éric Araujo :


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

___
Python tracker 

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

[issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map

[Éric Araujo]

Éric Araujo  added the comment:

+1 on adding SVG types in 3.2 or 3.3.

--
nosy: +eric.araujo

___
Python tracker 

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

[issue10254] unicodedata.normalize('NFC', s) regression

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Attached patch, issue10254a.diff, adds the OP's cases to test_unicodedata and 
changes the code as I suggested in msg124173 because ISTM that comb >= comb1 
matches the pr-29 definition:

"""
D2'. In any character sequence beginning with a starter S, a character C is 
blocked from S if and only if there is some character B between S and C, and 
either B is a starter or it has the same or higher combining class as C.
""" http://www.unicode.org/review/pr-29.html

Unfortunately, all tests pass with either comb >= comb1 or comb == comb1, so 
before I commit, I would like to figure out the test case that would properly 
exercise this code.

--
Added file: http://bugs.python.org/file20120/issue10254a.diff

___
Python tracker 

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

[issue3871] cross and native build of python for mingw32 with distutils

[alesko]

Changes by alesko :


--
nosy: +alesko

___
Python tracker 

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

[issue10742] memoryview.readonly attribute is not documented

[flashk]

New submission from flashk :

The 'readonly' attribute is not explicitly described, even though it is used in 
the sample code for the memoryview type.

I've attached a patch that adds a description of the 'readonly' attribute.

--
assignee: d...@python
components: Documentation
files: stdtypes.diff
keywords: patch
messages: 124403
nosy: d...@python, flashk
priority: normal
severity: normal
status: open
title: memoryview.readonly attribute is not documented
versions: Python 2.7
Added file: http://bugs.python.org/file20121/stdtypes.diff

___
Python tracker 

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

[issue1243654] Faster output if message already has a boundary

[R. David Murray]

R. David Murray  added the comment:

Turns out there's a bug in my version of the patch, and no test in the email 
test suite traversed that code path.

Attached patch fixes this; I'll commit and backport after trunk unfreezes.  
Note that the backport contains a second bug (calls self._make_boundary when it 
should be just _make_boundary)

--
status: closed -> open
Added file: http://bugs.python.org/file20122/boundar_fix_fix.patch

___
Python tracker 

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

[issue10743] 3.2's sysconfig doesn't work with virtualenv

[Sridhar Ratnakumar]

New submission from Sridhar Ratnakumar :

>From http://code.google.com/p/virtualenv5/issues/detail?id=6 - it seems that 
>the `sysconfig` module is looking for Makefile in wrong directory, while 
>ideally it must be looking into the base Python install.

>> import sysconfig; sysconfig.get_paths('purelib')
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", 
line 332, in _init_posix
_parse_makefile(makefile, vars)
  File 
"/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", 
line 220, in _parse_makefile
with open(filename, errors="surrogateescape") as f:
IOError: [Errno 2] No such file or directory: 
'/tmp/e/lib/python3.2/config-3.2m/Makefile'

--
assignee: tarek
components: Distutils, Macintosh
messages: 124405
nosy: eric.araujo, srid, tarek
priority: normal
severity: normal
status: open
title: 3.2's sysconfig doesn't work with virtualenv
type: behavior
versions: Python 3.2

___
Python tracker 

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

[issue10744] ctypes arrays have incorrect buffer information (PEP-3118)

[Pauli Virtanen]

New submission from Pauli Virtanen :

Ctypes arrays have invalid buffer interface information (on Python 3.1.2):

>>> import ctypes
>>> x = (ctypes.c_double*2)()
>>> y = memoryview(x)
>>> y.shape
(2,)
>>> y.format
'(2)http://projects.scipy.org/numpy/ticket/1699)

--
assignee: theller
components: ctypes
files: 001-ctypes-fix-pep-3118-format-strings-for-arrays.patch
keywords: patch
messages: 124406
nosy: pv, theller
priority: normal
severity: normal
status: open
title: ctypes arrays have incorrect buffer information (PEP-3118)
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: 
http://bugs.python.org/file20123/001-ctypes-fix-pep-3118-format-strings-for-arrays.patch

___
Python tracker 

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

[issue10740] sqlite3 module should allow DDL statements in transactions

[Scott Urban]

Scott Urban  added the comment:

I find the way that the sqlite3 module handles transactions pretty
surprising in general, but I agree that someone who got used
to DDL not rolling back could in theory find this patch surprising.

We will apply this patch to our python build because having DDL
covered by a transactions is convenient for certain tasks. If anyone
can think of a problem with this simple patch, I'd like to hear it.

Thanks
Scott

--

___
Python tracker 

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

[issue10745] --user option, per user site-packages undocumented in Installing Python Modules document

[Chris Lasher]

New submission from Chris Lasher :

Python 2.6 saw the introduction of per user site-packages directory for easy 
installation of Python packages into a guaranteed location in which the user 
has appropriate permissions.

http://bugs.python.org/issue1799
http://www.python.org/dev/peps/pep-0370/
http://docs.python.org/whatsnew/2.6.html#pep-370-per-user-site-packages-directory

With it came a new option available in distutils-powered setup.py scripts, 
"--user". It has been a year since this feature was introduced, yet no 
documentation has appeared in the official Python Documentation other than in 
the "What's New" document. Specifically, this option should appear and be 
documented in the "Installing Python Modules" document.

http://docs.python.org/install/

It would be very helpful if the documentation described the advantages of using 
this option over "--home" and "--prefix".

I am not the first user to notice this gap in the documentation, e.g.,

http://www.devx.com/opensource/Article/42353/1763

however, I couldn't find any bugs open for this issue so I have created this 
new one.

--
assignee: tarek
components: Distutils, Documentation
messages: 124408
nosy: eric.araujo, gotgenes, tarek
priority: normal
severity: normal
status: open
title: --user option, per user site-packages undocumented in Installing Python 
Modules document
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

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

[issue10087] HTML calendar is broken

[Ron Adam]

Ron Adam  added the comment:

The problem is in the following line...

return ''.join(v).encode(encoding, "xmlcharrefreplace")

The .encode(encoding, "xmlcharrefreplace") is returning a bytes object.

Here is the simplest change to resolve the problem.

return str(''.join(v).encode(encoding, "xmlcharrefreplace"),
encoding=encoding)

But maybe a different way to implement "xmlcharrefreplace" is what is needed.  
Would it be better if it were a function or method in the xml (or html) module?

Just because it can be implemented as an encoding doesn't mean it should be.

--

___
Python tracker 

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

[issue10745] setup.py install --user option undocumented

[Éric Araujo]

Changes by Éric Araujo :


--
assignee: tarek -> eric.araujo
components: +Distutils2 -Distutils
title: --user option, per user site-packages undocumented in Installing Python 
Modules document -> setup.py install --user option undocumented
versions: +3rd party -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

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

[issue10087] HTML calendar is broken

[Chris Lambacher]

Chris Lambacher  added the comment:

Sorry in advance for the long winded response.

Ron, have you looked at my patch?

The underlying issue is that the semantics for print() between Python 1 and 3. 
print() does not accept a bytes type in Python 3. In Python 2 str was a "bytes" 
type and so print happily sent encoded strings to stdout. 

This presents an issue for both --type=html and the text version if an encoding 
is asked for. Just using print() will result in repr being called on the byte 
string and you get either an invalid HTML file or a text file with extra junk 
in it (same junk in both).

If you ask for an encoding, you are going to get bytes. Changing it back into a 
string to mask that effect does not actually fix things for you because once 
you do print() you are back to a default encoding and therefore more broken 
because you are not doing what the user asked for (which is a particular 
encoding).

In order for:
return str(''.join(v).encode(encoding, "xmlcharrefreplace"),
encoding=encoding)

to solve the issue, you would also need to take away the ability for the user 
to specify an encoding (at the command line and via the API). It's already a 
string, why make it a byte and then a string again? If you don't want to deal 
with encoding, then return a string and leave it up to the consumer of the API 
to handle the desired encoding (and the "xmlcharrefreplace", maybe with a note 
in the docs).

If you do want to deal with encoding (which I think we are stuck with), then 
solve the real issue by not using print() (see my patch).

I think the only reason that my patch was not accepted, and why this is still 
languishing is that I said I would provide tests and have not had time to do 
so. 

Please feel free to correct me if I am wrong about any of the above.

--

___
Python tracker 

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

[issue10746] ctypes c_long & c_bool have incorrect PEP-3118 type codes

[Pauli Virtanen]

New submission from Pauli Virtanen :

Currently on Python 3.x:

>>> import ctypes
>>> memoryview(ctypes.c_long()).format
'http://bugs.python.org/issue10744 ):

>>> import numpy as np
>>> from ctypes import *
>>> class Point(Structure):
... _fields_ = [("x", c_long), ("y", c_long)]
... 
>>> class StructWithArrays(Structure):
... _fields_ = [("x", c_long * 3 * 2), ("y", Point * 4)]
... 
>>> x = StructWithArrays()
>>> y = np.asarray(x)
>>> y.dtype
dtype([('x', '>> y['x'] = [[1,2,3],[4,5,6]]
>>> y['y']['x'] = np.arange(4) + 10
>>> y['y']['y'] = np.arange(4) + 20
>>> x.x[0][0]
1
>>> x.x[0][1]
2
>>> x.x[0][2]
3
>>> x.y[0].x
10
>>> x.y[1].x
11
>>> x.y[0].y
20
>>> x.y[1].y
21

--
files: 001-ctypes-fix-pep-3118-type-codes-for-c-long-and-c-bool.patch
keywords: patch
messages: 124411
nosy: pv
priority: normal
severity: normal
status: open
title: ctypes c_long & c_bool have incorrect PEP-3118 type codes
Added file: 
http://bugs.python.org/file20124/001-ctypes-fix-pep-3118-type-codes-for-c-long-and-c-bool.patch

___
Python tracker 

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

[issue10746] ctypes c_long & c_bool have incorrect PEP-3118 type codes

[Pauli Virtanen]

Changes by Pauli Virtanen :


--
assignee:  -> theller
components: +ctypes
nosy: +theller
type:  -> behavior
versions: +Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

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

[issue10743] 3.2's sysconfig doesn't work with virtualenv

[Ned Deily]

Ned Deily  added the comment:

That does seem to be a regression since distutils.sysconfig works correctly in 
a virtualenv:

$ python3.2 -c 'import 
distutils.sysconfig;print(distutils.sysconfig.get_makefile_filename())'
/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/config-3.2m/Makefile
$ python3.2 -c 'import sysconfig;print(sysconfig.get_makefile_filename())'
/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/config-3.2m/Makefile

but in a virtualenv:

$ source t/bin/activate
$ python3.2 -c 'import 
distutils.sysconfig;print(distutils.sysconfig.get_makefile_filename())'
/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/config-3.2m/Makefile
$ python3.2 -c 'import sysconfig;print(sysconfig.get_makefile_filename())'
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", 
line 332, in _init_posix
_parse_makefile(makefile, vars)
  File 
"/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", 
line 220, in _parse_makefile
with open(filename, errors="surrogateescape") as f:
IOError: [Errno 2] No such file or directory: 
'/Users/nad/t/lib/python3.2/config-3.2m/Makefile'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File 
"/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", 
line 322, in get_makefile_filename
return os.path.join(get_path('stdlib'),
  File 
"/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", 
line 451, in get_path
return get_paths(scheme, vars, expand)[name]
  File 
"/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", 
line 442, in get_paths
return _expand_vars(scheme, vars)
  File 
"/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", 
line 168, in _expand_vars
_extend_dict(vars, get_config_vars())
  File 
"/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", 
line 487, in get_config_vars
_init_posix(_CONFIG_VARS)
  File 
"/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/sysconfig.py", 
line 337, in _init_posix
raise IOError(msg)


BTW, your example will fail in any case since get_paths takes a scheme name; 
"purelib" is a path name.

--
nosy: +barry, ned.deily

___
Python tracker 

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

[issue10743] 3.2's sysconfig doesn't work with virtualenv

[Ned Deily]

Ned Deily  added the comment:

Setting to deferred blocker for 3.2 release manager evaluation.

--
nosy: +georg.brandl
priority: normal -> deferred blocker

___
Python tracker 

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

[issue10740] sqlite3 module should allow DDL statements in transactions

[Andrew Svetlov]

Changes by Andrew Svetlov :


--
nosy: +asvetlov

___
Python tracker 

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

[issue10087] HTML calendar is broken

[Ron Adam]

Ron Adam  added the comment:

Oops.  You're right.  

I miss understood how the encode method works in this particular case. ;-/

I agree with your comments as well.

--

___
Python tracker 

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

[issue10715] uninformative error message

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

I eventually determined that a call to `subprocess.Popen` was responsible
for the message, but could have determined this much more quickly if the
message had included the name of the file that could not be opened
(executed).

Phillip

On Mon, Dec 20, 2010 at 11:20 AM, Éric Araujo wrote:

>
> Changes by Éric Araujo :
>
>
> --
> components: +IO
> nosy: +eric.araujo
> versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6
>
> ___
> Python tracker 
> 
> ___
>

--
nosy: +phillip.m.feld...@gmail.com
Added file: http://bugs.python.org/file20125/unnamed

___
Python tracker 

___I eventually determined that a call to `subprocess.Popen` was responsible for 
the message, but could have determined this much more quickly if the message 
had included the name of the file that could not be opened (executed).
PhillipOn Mon, Dec 20, 2010 at 11:20 AM, 
Éric Araujo rep...@bugs.python.org> 
wrote:

Changes by Éric Araujo mer...@netwok.org>:


--
components: +IO
nosy: +eric.araujo
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

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

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

[issue10715] uninformative error message

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


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

___
Python tracker 

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

[issue10715] uninformative error message

[Phillip M. Feldman]

Phillip M. Feldman  added the comment:

Why was this removed?

On Mon, Dec 20, 2010 at 8:30 PM, Alexander Belopolsky <
rep...@bugs.python.org> wrote:

>
> Changes by Alexander Belopolsky :
>
>
> Removed file: http://bugs.python.org/file20125/unnamed
>
> ___
> Python tracker 
> 
> ___
>

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

___
Python tracker 

___Why was this removed?On Mon, Dec 20, 2010 at 
8:30 PM, Alexander Belopolsky rep...@bugs.python.org> 
wrote:

Changes by Alexander Belopolsky belopol...@users.sourceforge.net>:


Removed file: http://bugs.python.org/file20125/unnamed"; 
target="_blank">http://bugs.python.org/file20125/unnamed

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

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

[issue10254] unicodedata.normalize('NFC', s) regression

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Mon, Dec 20, 2010 at 2:50 PM, Alexander Belopolsky
 wrote:
..
> Unfortunately, all tests pass with either comb >= comb1 or comb == comb1, so 
> before
> I commit, I would like to figure out the test case that would properly 
> exercise this code.
>

After some more thought, I've realized that the comb > comb1 case is
impossible if comb1 != 0 (due to canonical reordering step) and if
comb1 == 0, the comb1 to comb comparison is not reached.  In other
words, it does not matter whether comparison is done as Martin
suggested in msg120018 or as it is done in the latest patch.  The fact
that comb > comb1 case is impossible if comb1 != 0 is actually
mentioned in PR 29 itself.  See Table 1: Differences at
http://www.unicode.org/review/pr-29.html.

--

___
Python tracker 

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