[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Martin v . Löwis]

Martin v. Löwis added the comment:

Instead of using "mkdir -p", it should use $(MKDIR_P) (which actually isn't 
normally "mkdir -p" :-) Other than that, the patch looks fine.

--
nosy: +loewis

___
Python tracker 

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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Trent Nelson]

Trent Nelson added the comment:

Hm.  Now I'm confused.  Is this what you meant?

---
% hg diff
diff -r 019a2390b014 Makefile.pre.in
--- a/Makefile.pre.in   Tue Aug 21 23:41:43 2012 +
+++ b/Makefile.pre.in   Thu Aug 30 07:16:55 2012 +
@@ -43,6 +43,8 @@
 
 GNULD= @GNULD@
 
+MKDIR_P=   @MKDIR_P@
+
 # Shell used by make (some versions default to the login shell, which is bad)
 SHELL= /bin/sh
 
@@ -223,8 +225,8 @@
 
 ##
 # Grammar
-GRAMMAR_H= $(srcdir)/Include/graminit.h
-GRAMMAR_C= $(srcdir)/Python/graminit.c
+GRAMMAR_H= Include/graminit.h
+GRAMMAR_C= Python/graminit.c
 GRAMMAR_INPUT= $(srcdir)/Grammar/Grammar
 
 
@@ -266,9 +268,9 @@
 
 ##
 # AST
-AST_H_DIR= $(srcdir)/Include
+AST_H_DIR= Include
 AST_H= $(AST_H_DIR)/Python-ast.h
-AST_C_DIR= $(srcdir)/Python
+AST_C_DIR= Python
 AST_C= $(AST_C_DIR)/Python-ast.c
 AST_ASDL=  $(srcdir)/Parser/Python.asdl
 
@@ -605,9 +607,11 @@
 Parser/pgenmain.o: $(srcdir)/Include/parsetok.h
 
 $(AST_H): $(AST_ASDL) $(ASDLGEN_FILES)
+   $(MKDIR_P) $(AST_H_DIR)
$(ASDLGEN) -h $(AST_H_DIR) $(AST_ASDL)
 
 $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES)
+   $(MKDIR_P) $(AST_C_DIR)
$(ASDLGEN) -c $(AST_C_DIR) $(AST_ASDL)
 
 Python/compile.o Python/symtable.o Python/ast.o: $(GRAMMAR_H) $(AST_H)
diff -r 019a2390b014 configure
--- a/configure Tue Aug 21 23:41:43 2012 +
+++ b/configure Thu Aug 30 07:16:55 2012 +
@@ -658,6 +658,7 @@
 GNULD
 LINKCC
 LDVERSION
+MKDIR_P
 RUNSHARED
 INSTSONAME
 LDLIBRARYDIR
@@ -5262,6 +5263,7 @@
 HGBRANCH=""
 fi
 
+MKDIR_P="mkdir -p"
 
 DISABLE_ASDLGEN=""
 # Extract the first word of "python", so it can be a program name with args.
---

Given your "which actually isn't normally mkdir -p" comment... my patch doesn't 
seem right.

--

___
Python tracker 

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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Martin v . Löwis]

Martin v. Löwis added the comment:

Am 30.08.12 09:19, schrieb Trent Nelson:
> Hm.  Now I'm confused.  Is this what you meant?

No. Makefile.pre.in *already* has a definition of MKDIR_P, no need to 
add one.

--
title: Unable to build Python out-of-tree when source tree is readonly. -> 
Unable to build Python out-of-tree when source tree is   readonly.

___
Python tracker 

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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Trent Nelson]

Trent Nelson added the comment:

That's what I figured you meant initially... Until I couldn't find any MKDIR_P 
definitions, and couldn't get it working without the hack above.

I thought it might be an implicit make variable as well, but, not so much.  
(Tested with BSD make and gmake on FreeBSD.)

--

___
Python tracker 

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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Petri Lehtinen]

Petri Lehtinen added the comment:

In 3.3, Makefile.pre.in already defines MKDIR_P, in 3.2 it doesn't.

--
nosy: +petri.lehtinen

___
Python tracker 

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

[issue15820] Add additional info to Resources area on Dev Guide

[Mike Hoy]

Changes by Mike Hoy :


--
keywords: +patch
Added file: http://bugs.python.org/file27055/devguide-resources.diff

___
Python tracker 

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

[issue15820] Add additional info to Resources area on Dev Guide

[Mike Hoy]

New submission from Mike Hoy:

I wrote a patch which adds more info the devguide under Resources: 
http://docs.python.org/devguide/index.html#resources

--
messages: 169436
nosy: mikehoy
priority: normal
severity: normal
status: open
title: Add additional info to Resources area on Dev Guide
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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Trent Nelson]

Trent Nelson added the comment:

Ah, I see the MKDIR_P changes in 3.x/configure as well.

Objections to backporting to 3.2?

Is 2.7 off the table?

(Building from a readonly source is handy for Snakebite; saves having a dozen 
machines needing to use their own hg clone.)

--

___
Python tracker 

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

[issue15820] Add additional info to Resources area on Dev Guide

[Mike Hoy]

Changes by Mike Hoy :


Added file: http://bugs.python.org/file27056/devguide-resources-2.diff

___
Python tracker 

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

[issue15820] Add additional info to Resources area on Dev Guide

[Mike Hoy]

Mike Hoy added the comment:

I changed the wording a bit and added a few more things. The second one is the 
one I prefer.

--

___
Python tracker 

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

[issue15820] Add additional info to Resources area on Dev Guide

[Mike Hoy]

Mike Hoy added the comment:

I'm working on a new patch with Ezio.

--

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Stefan Krah]

Stefan Krah added the comment:

Martin v. L??wis  wrote:
> > hash(x) == hash(x.tobytes())
> In the light of this requirement, it's even more difficult to ask
> people that they change their hashing, since some exporters may already
> comply with that original request.

I don't think so. memoryview.__hash__() is new in 3.3 and the requirement
is not documented at all in the general PEP-3118 sections.

[Adding Stefan Behnel to nosy, since Cython is pretty quick to pick up
new features.]

> > The new equality definition and any possible new hash definition should
> > probably also be part of the buffer API documentation, since they
> > aren't memoryview specific.
> 
> That's not true: they *are* memoryview-specific. The notion of equality
> is entirely one of memoryview objects, not of buffers.

Could you name a part of the equality definition that is memoryview-specific?

> I still maintain that specifying hashing for memoryviews under the
> new equality definition is just not feasible, and that we should give
> up on it (except perhaps supporting the hashing of bytes views).
> I also question whether it is useful to hash arbitrarily-shaped
> read-only buffers (along with questioning whether people will actually
> *have* arbitrarily-shaped read-only buffers).

Useful, perhaps. I don't know if it is worth the effort though. We
could restrict hashing to contiguous bytes views in 3.3.1.

--

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Stefan Krah]

Changes by Stefan Krah :


--
nosy: +scoder

___
Python tracker 

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

[issue15820] Add additional info to Resources area on Dev Guide

[Mike Hoy]

Mike Hoy added the comment:

This patch adds a link from:
http://docs.python.org/devguide/index.html#resources

To:
http://docs.python.org/devguide/docquality.html#helping-with-the-developer-s-guide

--
Added file: http://bugs.python.org/file27057/devguide-resources-3.diff

___
Python tracker 

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

[issue15820] Add additional info to Resources area on Dev Guide

[Mike Hoy]

Mike Hoy added the comment:

It was determined by Ezio that the previous patches had too much information 
about how to open a browser, or install python-sphynx on a debian system. It 
was just out of scope for the docs (people should know how to use their package 
management systems, etc). We worked out that it was best to just use the 
existing docs for stuff like hg clone... and leave out the sudo apt-get install 
python-sphynx.

--

___
Python tracker 

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

[issue15821] Improve docs for PyMemoryView_FromBuffer()

[Stefan Krah]

New submission from Stefan Krah:

People are using PyMemoryView_FromBuffer() to create and return
permanent memoryviews from buffers that are allocated on the stack.
See:

http://stackoverflow.com/questions/8123121/how-to-get-back-a-valid-object-from-python-in-c-while-this-object-has-been-con


The docs should perhaps warn against this.

--
assignee: docs@python
components: Documentation
messages: 169443
nosy: belopolsky, docs@python, ncoghlan, pitrou, skrah
priority: normal
severity: normal
status: open
title: Improve docs for  PyMemoryView_FromBuffer()
type: enhancement
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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Martin v . Löwis]

Martin v. Löwis added the comment:

Am 30.08.12 09:47, schrieb Trent Nelson:
> Objections to backporting to 3.2?
>
> Is 2.7 off the table?

No, adding AC_PROG_MKDIR_P into all of them is fine.

--

___
Python tracker 

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

[issue15822] Python 3.3 creates lib2to3 grammar in wrong order

[Tomi Pieviläinen]

New submission from Tomi Pieviläinen:

Python 3.3rc1 source install modifies/installs lib2to3/Grammar.txt after 
modifying Grammar3.3.0.candidate.1.pickle:

-rw-r--r--. 1 root root  6589 2012-08-27 13:25:33.190414570 +0300 Grammar.txt
-rw-r--r--. 1 root root 20622 2012-08-27 13:25:33.150477192 +0300 
Grammar3.3.0.candidate.1.pickle

This causes lib2to3/pgen2/driver:load_grammar to try to recreate the pickle 
(the _newer call on line 119 returns false), which triggers SandboxViolation in 
when using easy_install/distribute 
(https://bitbucket.org/tarek/distribute/issue/317/easy_install-fails-with-sandboxviolation)
 see .

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 169445
nosy: tpievila
priority: normal
severity: normal
status: open
title: Python 3.3 creates lib2to3 grammar in wrong order
type: behavior
versions: Python 3.3

___
Python tracker 

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

[issue15724] Add "versionchanged" to memoryview docs

[Roundup Robot]

Roundup Robot added the comment:

New changeset 34e8c06f7e55 by Stefan Krah in branch 'default':
Issue #15724: Add versionchanged tags to the memoryview documentation.
http://hg.python.org/cpython/rev/34e8c06f7e55

--
nosy: +python-dev

___
Python tracker 

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

[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed

[Antoine Pitrou]

Antoine Pitrou added the comment:

I haven't tested Ross's latest patch, but it looks ok to me.

--
stage:  -> patch review

___
Python tracker 

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

[issue10650] decimal.py: quantize(): excess digits with watchexp=0

[Roundup Robot]

Roundup Robot added the comment:

New changeset 7db16ff9f5fd by Stefan Krah in branch 'default':
Closes #10650: Deprecate the watchexp parameter of Decimal.quantize().
http://hg.python.org/cpython/rev/7db16ff9f5fd

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

[issue15724] Add "versionchanged" to memoryview docs

[Stefan Krah]

Changes by Stefan Krah :


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

___
Python tracker 

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

[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed

[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

[issue15818] multiprocessing documentation of Process.exitcode

[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

[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed

[Richard Oudkerk]

Richard Oudkerk added the comment:

Would it simplify matters to stop treating 0,1,2 specially and just add them to 
pass_fds instead?

--
nosy: +sbt

___
Python tracker 

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

[issue15616] logging.FileHandler not correctly created with PyYaml (unpickling problems?)

[Vinay Sajip]

Changes by Vinay Sajip :


--
status: pending -> closed

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Stefan Krah]

Stefan Krah added the comment:

Here's a doc patch restricting the hash to formats 'B', 'b' and 'c'.
I think non-contiguous views are fine: both __eq__() and tobytes()
handle these, so the equality-hash invariant is preserved.

--

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Stefan Krah]

Changes by Stefan Krah :


--
keywords: +patch
Added file: http://bugs.python.org/file27058/issue15814-doc.diff

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Martin v . Löwis]

Martin v. Löwis added the comment:

Am 30.08.12 11:24, schrieb Stefan Krah:
>>> The new equality definition and any possible new hash definition should
>>> probably also be part of the buffer API documentation, since they
>>> aren't memoryview specific.
>>
>> That's not true: they *are* memoryview-specific. The notion of equality
>> is entirely one of memoryview objects, not of buffers.
>
> Could you name a part of the equality definition that is memoryview-specific?

As literally spelled out, it starts with "a memoryview and a PEP 3118 
exporter". But I was actually thinking of the implementation...

In any case, I'm skeptical that this is a useful extension to the buffer 
interface. You would imply "two exporters are equal iff their exported 
buffers are equal". I think this is asking too much.

--

___
Python tracker 

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

[issue15822] Python 3.3 creates lib2to3 grammar in wrong order

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +benjamin.peterson, georg.brandl
priority: normal -> high

___
Python tracker 

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

[issue15821] Improve docs for PyMemoryView_FromBuffer()

[Stefan Krah]

Stefan Krah added the comment:

This may be a bigger problem (grep for image_surface_get_data):

http://lists.cairographics.org/archives/cairo/2011-December/022563.html


The previous semantics for PyMemoryView_FromBuffer(view) were:

  1) If non-NULL, steal the view.obj reference with automatic
 decrement in PyBuffer_Release().

  2) Copy shape and strides to view.smalltable.



The new semantics for PyMemoryView_FromBuffer(view) are:

  1) If non-NULL, treat view.obj as a borrowed reference.

  2) Rely on the fact that shape and strides won't disappear.


2) means that returning PyMemoryView_FromBuffer(view) from
a view allocated on the stack is no longer safe. In all instances
people could migrate to PyMemoryView_FromMemory(), which is
both safe and more convenient, but code may be broken.

PyManaged_Buffer is designed to expect buffers from exporters,
where it is guaranteed that the buffers won't disappear,so it
won't be easy to keep backwards compatibility.

--
priority: normal -> high

___
Python tracker 

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

[issue15776] Allow pyvenv to work in existing directory

[Vinay Sajip]

Changes by Vinay Sajip :


--
nosy: +carljm

___
Python tracker 

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

[issue15799] httplib client and statusline

[karl]

karl added the comment:

So what do we do with it? 
Do I created a patch or do we close that bug? :)
No hard feelings about it.

--

___
Python tracker 

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

[issue15799] httplib client and statusline

[Antoine Pitrou]

Antoine Pitrou added the comment:

Well, I'd like to hear Senthil's opinion, since he's the main http / urllib 
maintainer these days.

--
versions: +Python 3.3 -Python 3.2

___
Python tracker 

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

[issue15799] httplib client and statusline

[R. David Murray]

R. David Murray added the comment:

I'm inclined to think it isn't worth the effort, myself.  I think a 
"validating" client would be a valuable tool, but that that isn't what the 
stdlib is focused on.  But yes, let's hear Senthil's opinion.

(That said, I am in fact adding a lot of validation capabilities to the email 
package...but in general those are only a matter of exposing the information 
about parsing failures that the code then has to recover from, rather than 
adding extra parsing to detect non-compliance.)

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

[issue15823] argparse produces error when multiply help lines

[Nikolay Golub]

New submission from Nikolay Golub:

When i use this code:
  parser.add_argument('-r', '--range',
action = 'store',
dest = 'ranges',
nargs = 2,
metavar = 'RANGE',
required = False,
help = 'Start and end range date and time for report 
data.'\
'Timeformat is %y-%m-%d %H:%M:%S'\
'for example -r "2012-08-20 14:48:39 
"2012-08-25 15:35:00"'
)

I get this error:


Traceback (most recent call last):
  File "./create_report.py", line 166, in 
main()
  File "./create_report.py", line 123, in main
args = parser.parse_args()
  File "/usr/lib/python2.7/argparse.py", line 1688, in parse_args
args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib/python2.7/argparse.py", line 1720, in parse_known_args
namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib/python2.7/argparse.py", line 1926, in _parse_known_args
start_index = consume_optional(start_index)
  File "/usr/lib/python2.7/argparse.py", line 1866, in consume_optional
take_action(action, args, option_string)
  File "/usr/lib/python2.7/argparse.py", line 1794, in take_action
action(self, namespace, argument_values, option_string)
  File "/usr/lib/python2.7/argparse.py", line 994, in __call__
parser.print_help()
  File "/usr/lib/python2.7/argparse.py", line 2313, in print_help
self._print_message(self.format_help(), file)
  File "/usr/lib/python2.7/argparse.py", line 2287, in format_help
return formatter.format_help()
  File "/usr/lib/python2.7/argparse.py", line 279, in format_help
help = self._root_section.format_help()
  File "/usr/lib/python2.7/argparse.py", line 209, in format_help
func(*args)
  File "/usr/lib/python2.7/argparse.py", line 209, in format_help
func(*args)
  File "/usr/lib/python2.7/argparse.py", line 515, in _format_action
help_text = self._expand_help(action)
  File "/usr/lib/python2.7/argparse.py", line 601, in _expand_help
return self._get_help_string(action) % params
ValueError: unsupported format character 'y' (0x79) at index 65

i think that it sin't normal. i always cut strings like these, according to pep8

--
components: Library (Lib)
messages: 169456
nosy: Nikolay.Golub
priority: normal
severity: normal
status: open
title: argparse produces error when multiply help lines
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

[issue15823] argparse produces error when multiply help lines

[R. David Murray]

R. David Murray added the comment:

The problem is the timeformat.  % codes are used to include data into the 
strings, so if you want a literal % in the help string, you need to double it.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue15823] argparse produces error when multiply help lines

[R. David Murray]

Changes by R. David Murray :


--
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Roundup Robot]

Roundup Robot added the comment:

New changeset 62044cd5b19b by Trent Nelson in branch '3.2':
Issue #15819: Fix out-of-tree builds from a readonly source.
http://hg.python.org/cpython/rev/62044cd5b19b

--
nosy: +python-dev

___
Python tracker 

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

[issue15823] argparse produces error when multiply help lines

[Nikolay Golub]

Nikolay Golub added the comment:

thanks!

--

___
Python tracker 

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

[issue15821] Improve docs for PyMemoryView_FromBuffer()

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Having been bitten by an indirect buffer bug in 2.7, I decided to write some 
tests for 3.3.  I added an objview() function to _testbuffer module that 
creates an indirect view for nested tuples.  I have not written unit tests yet, 
so I'll attach a demo script test_indirect.py.

I hope this test case will be helpful in figuring out the right semantics for 
PyMemoryView_FromBuffer().  My feeling is that memoryview should be able to 
store shape/strides/suboffsets arrays in its own structure.  I also think the 
only way to achieve that is to make it a PyVarObject and allocate up to 
sizeof(Py_ssize_t)*ndim*3 bytes after the "view" substructure to store copies 
of shape/strides/suboffsets arrays.

--
keywords: +patch
Added file: http://bugs.python.org/file27059/_testbuffer.diff

___
Python tracker 

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

[issue15821] Improve docs for PyMemoryView_FromBuffer()

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


Added file: http://bugs.python.org/file27060/test_indirect.py

___
Python tracker 

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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Roundup Robot]

Roundup Robot added the comment:

New changeset af36536988fd by Trent Nelson in branch 'default':
Block 78809:62044cd5b19b (Issue #15819) from 3.2.
http://hg.python.org/cpython/rev/af36536988fd

--

___
Python tracker 

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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Roundup Robot]

Roundup Robot added the comment:

New changeset ab6ab44921b2 by Trent Nelson in branch 'default':
Issue #15819: Fix out-of-tree builds from a readonly source.
http://hg.python.org/cpython/rev/ab6ab44921b2

--

___
Python tracker 

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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Roundup Robot]

Roundup Robot added the comment:

New changeset 2dde5a7439fd by Trent Nelson in branch '2.7':
Issue #15819: Fix out-of-tree builds from a readonly source.
http://hg.python.org/cpython/rev/2dde5a7439fd

--

___
Python tracker 

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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Trent Nelson]

Changes by Trent Nelson :


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

[issue15821] Improve docs for PyMemoryView_FromBuffer()

[Stefan Krah]

Stefan Krah added the comment:

PyMemoryViewObject already is a PyVarObject with its own shape, strides
and suboffsets. It is the PyManagedBuffer object that directly communicates
with exporters.

The decision to store *exactly* the buffer that is obtained from the
exporter was made in #10181.

Your test case seems to pass here. :) Was it supposed to crash?

--

___
Python tracker 

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

[issue9860] Building python outside of source directory fails

[Trent Nelson]

Trent Nelson added the comment:

FWIW, `make patchcheck` fails for me as follows:


% make patchcheck
./python /home/trent/hg/cpython-3.2/Tools/scripts/patchcheck.py
Getting the list of files that have been added/changed ... abort: no repository 
found in '/tmp/cpython-3.2-build' (.hg not found)!
0 files
Fixing whitespace ... 0 files
Fixing C file whitespace ... 0 files
Fixing docs whitespace ... 0 files
Docs modified ... NO
Misc/ACKS updated ... NO
Misc/NEWS updated ... NO
[51233 refs]

patchcheck.py needs to be modified so that it cd's into SRCDIR before running 
any hg commands.

--

___
Python tracker 

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

[issue15821] Improve docs for PyMemoryView_FromBuffer()

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

> Your test case seems to pass here. :) Was it supposed to crash?

No, I worked real hard to make it pass. :-)  I think it would crash 2.7 and 
3.2, but I have not tried.  I also suspect it leaks memory.

Do you think this is something that we should include in the test suit.  If so, 
I will probably open a separate issue and transform test_indirect.py into a 
patch for test_buffer.

--

___
Python tracker 

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

[issue15821] Improve docs for PyMemoryView_FromBuffer()

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

> PyMemoryViewObject already is a PyVarObject with its own shape,
> strides and suboffsets.

You are right.  I was mistakenly looking at 3.2.3 sources. It looks like there 
are a lot of undocumented changes here.

--

___
Python tracker 

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

[issue2988] Invalid cookies crash web applications

[Shish]

Shish added the comment:

I'm having problems with this too -- a third party app on the same domain as me 
has set an invalid cookie, and now my app crashes horribly :(

(And even if cherrypy handled the exception and didn't crash completely, it 
would still not be able to use any cookies)

--
nosy: +shish2k

___
Python tracker 

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

[issue2988] Invalid cookies crash web applications

[R. David Murray]

R. David Murray added the comment:

There is some extensive (and somewhat contentious) discussion of this on issue 
2193.  I myself am sympathetic to having a mode where parsing errors are 
handled in a more convenient fashion, but it would pretty much have to be a new 
feature.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue15822] Python 3.3 creates lib2to3 grammar in wrong order

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue12014] str.format parses replacement field incorrectly

[Éric Araujo]

Éric Araujo added the comment:

You can bring this up to python-dev to get other developers’ opinion.

--

___
Python tracker 

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

[issue15821] Improve docs for PyMemoryView_FromBuffer()

[Stefan Krah]

Stefan Krah added the comment:

On second thought, it's impossible to crash a memoryview generated
by PyMemoryView_FromBuffer(info) even when info->shape etc. point
to stack addresses.

The reason is this: All new memoryviews are created through the mbuf_add*
API. In the first call to mbuf_add_view(mbuf, NULL) the stack addresses
are still valid, and the private shape, strides and suboffsets of the
first memoryview that is registered with the managed buffer are
initialized correctly.

Now PyMemoryView_FromBuffer() returns and the managed buffer itself
contains invalid stack addresses. But these are never used again!

Chained memoryviews are generated from existing memoryviews, and
they are registered with the managed buffer by calling
mbuf_add_view(mbuf, existing_view->view).

mbuf_add_incomplete_view(mbuf, NULL, ndim) does not access shape, strides
and suboffsets.

If info->format points to a stack address, it would crash both the
old and new implementations. I'd regard such a use of info->format
silly.

I've never considered this use of PyMemoryView_FromBuffer(info) legitimate,
but it works in the new implementation. If we officially endorse this
pattern, then info->format should probably also be copied.

So the topic is reduced to:

  1) Previous: If non-NULL, steal the view.obj reference with automatic
   decrement in PyBuffer_Release().
 New:  If non-NULL, treat view.obj as a borrowed reference.

  2) Copy info->format?

--

___
Python tracker 

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

[issue15821] Improve docs for PyMemoryView_FromBuffer()

[Stefan Krah]

Changes by Stefan Krah :


--
priority: high -> normal

___
Python tracker 

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

[issue15821] Improve docs for PyMemoryView_FromBuffer()

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


Added file: http://bugs.python.org/file27061/_testbuffer.diff

___
Python tracker 

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

[issue15821] Improve docs for PyMemoryView_FromBuffer()

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

I've updated test_indirect.py to print all memoryview fields and cleaned up the 
_testbuffer patch a little.  Note this code that is needed to prevent a memory 
leak:

+/* PyMemoryView_FromBuffer ignores info.obj.  Add it explicitely. */
+if (view != NULL)
+  ((PyMemoryViewObject *)view)->view.obj = info.obj;

Shouldn't  PyMemoryView_FromBuffer() copy non-NULL obj from Py_buffer?

--
Added file: http://bugs.python.org/file27062/test_indirect.py

___
Python tracker 

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

[issue15821] Improve docs for PyMemoryView_FromBuffer()

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

On Thu, Aug 30, 2012 at 1:22 PM, Stefan Krah  wrote:
> So the topic is reduced to:
>
>   1) Previous: If non-NULL, steal the view.obj reference with automatic
>decrement in PyBuffer_Release().
>  New:  If non-NULL, treat view.obj as a borrowed reference.
>
>   2) Copy info->format?

+1 to both ideas.

--
nosy: +Alexander.Belopolsky
title: Improve docs for  PyMemoryView_FromBuffer() -> Improve docs for 
PyMemoryView_FromBuffer()

___
Python tracker 

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

[issue15821] Improve docs for PyMemoryView_FromBuffer()

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


Removed file: http://bugs.python.org/file27059/_testbuffer.diff

___
Python tracker 

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

[issue15821] Improve docs for PyMemoryView_FromBuffer()

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


Removed file: http://bugs.python.org/file27060/test_indirect.py

___
Python tracker 

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

[issue15824] mutable urlparse return type

[mastahyeti]

New submission from mastahyeti:

This patch removes the inheritance from namedtuple and attempts to add the 
necessary methods to make it backwards compatible.

When parsing a url with urlparse.urlparse, the return type is non-mutable 
(named tuple). This is really inconvenient, because one of the most common 
(imop) use cases for urlparse is to parse a url, make an adjustment or change 
and then unparse it. Currently, something like this is required:

import urlparse

url = list(urlparse.urlparse('http://www.example.com/foo/bar?hehe=haha'))
url[1] = 'python.com'
new_url = urllib.urlunparse(url)

I think this is really clunky. Moving to a mutable return type is challenging 
because (to my knowledge) there are no types that are mutable and compatible 
with tuple. This patch removes the inheritance from namedtuple and attempts to 
add the necessary methods to make it backwards compatible. Does any one know of 
a better way to do this? It would be nice if there were a namedlist type that 
acted like namedtuple but was mutable. 

With these updates, urlparse can be used as follows:

import urlparse

url = list(urlparse.urlparse('http://www.example.com/foo/bar?hehe=haha'))
url.netloc = 'www.python.com'
urlparse.urlunparse(url)

I think this is much better. Let me know if you disagree...

Also, I ran the script through autopep8 because it was messy.

Also, I'm not sure if I'm supposed to duplicate this patch over to Python3. I 
can do that if necessary

--
components: Library (Lib)
files: urlparse_patch.patch
keywords: patch
messages: 169474
nosy: mastahyeti
priority: normal
severity: normal
status: open
title: mutable urlparse return type
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file27063/urlparse_patch.patch

___
Python tracker 

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

[issue15824] mutable urlparse return type

[mastahyeti]

mastahyeti added the comment:

TYPO!!!

After my patch, urlparse can be used as such:

import urlparse

url = urlparse.urlparse('http://www.example.com/foo/bar?hehe=haha')
url.netloc = 'www.python.com'
urlparse.urlunparse(url)


The difference being that the result doesn't need to be casted to a list in 
order to be mutated...

--

___
Python tracker 

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

[issue15824] mutable urlparse return type

[Ezio Melotti]

Ezio Melotti added the comment:

This is a new feature, so it can't go in 2.7.

--
nosy: +ezio.melotti, orsenthil
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

[issue15824] mutable urlparse return type

[mastahyeti]

mastahyeti added the comment:

This is my first patch for python. Is there a feature freeze? Does it
need to go in Python3? Thanks.

On Thu, Aug 30, 2012 at 1:22 PM, Ezio Melotti  wrote:
>
> Ezio Melotti added the comment:
>
> This is a new feature, so it can't go in 2.7.
>
> --
> nosy: +ezio.melotti, orsenthil
> stage:  -> needs patch
> versions: +Python 3.4 -Python 2.7
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue15824] mutable urlparse return type

[R. David Murray]

R. David Murray added the comment:

I think the first step is probably to get consensus on whether this is 
desirable or not.  That might require a trip to python-idea, or it might not :)

As for the patch itself, you should definitely *not* include any changes other 
than the ones you are proposing.  Otherwise reviewing the patch is very 
difficult.

As Ezio said, as a new feature this could only go into 3.4, so the patch should 
be against the default branch in the mercurial repository.

--
nosy: +r.david.murray
stage: needs patch -> 

___
Python tracker 

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

[issue15824] mutable urlparse return type

[Senthil Kumaran]

Senthil Kumaran added the comment:

On Thu, Aug 30, 2012 at 11:17 AM, mastahyeti  wrote:
>
> When parsing a url with urlparse.urlparse, the return type is non-mutable 
> (named tuple). This is really inconvenient, because one of the most common 
> (imop) use cases for urlparse is to parse a url, make an adjustment or change 
> and then unparse it. Currently, something like this is required:

Not actually, using the namedtuple is a convenience and working
through way may help you to be generate your target url in a more
meaningful way. Also remember that we moved to namedtuple after
understanding that it is more meaningful to use that for parsed
result.  So, my vote for this proposal is -1. And if you need discuss
the strategies of how to use it, then you can ask over at python-help
or related lists.

--

___
Python tracker 

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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Richard Oudkerk]

Richard Oudkerk added the comment:

I tried building from out-of-tree with a read-only srcdir, but I found two 
other files which the build process tries to create in the source directory:

$(srcdir)/Objects/typeslots.inc
$(srcdir)/Lib/_sysconfigdata.py

--
nosy: +sbt

___
Python tracker 

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

[issue13769] json.dump(ensure_ascii=False) return str instead of unicode

[Petri Lehtinen]

Petri Lehtinen added the comment:

Attached yet another patch. It explains what input causes the result to be 
unicode instead of str.

--
Added file: http://bugs.python.org/file27064/issue13769_v3.patch

___
Python tracker 

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

[issue15824] mutable urlparse return type

[mastahyeti]

mastahyeti added the comment:

Senthil,
Can you give an example of how namedtuple would be more convenient? It
is definitely more convenient than an ordinary tuple, but its
inconvenient having its items not be assignable. As I showed in my
example above, it is usable as-is, but it is clunky. As David says
above, this obviously needs to be moved to another list for discussion
of whether the current behavior is desirable.

On Thu, Aug 30, 2012 at 1:38 PM, Senthil Kumaran  wrote:
>
> Senthil Kumaran added the comment:
>
> On Thu, Aug 30, 2012 at 11:17 AM, mastahyeti  wrote:
>>
>> When parsing a url with urlparse.urlparse, the return type is non-mutable 
>> (named tuple). This is really inconvenient, because one of the most common 
>> (imop) use cases for urlparse is to parse a url, make an adjustment or 
>> change and then unparse it. Currently, something like this is required:
>
> Not actually, using the namedtuple is a convenience and working
> through way may help you to be generate your target url in a more
> meaningful way. Also remember that we moved to namedtuple after
> understanding that it is more meaningful to use that for parsed
> result.  So, my vote for this proposal is -1. And if you need discuss
> the strategies of how to use it, then you can ask over at python-help
> or related lists.
>
> --
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue15824] mutable urlparse return type

[R. David Murray]

R. David Murray added the comment:

Actually, Senthil is right.  What you want is the _replace method of namedtuple 
to satisfy your use case.

--
resolution:  -> works for me
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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Martin v . Löwis]

Martin v. Löwis added the comment:

What I liked about Trent's original bug report is that it didn't just bring up 
a generic issue (cannot build with read-only source code), but clarified that 
his concern really was graminit.

So I'd like to declare that this (graminit) is the focus of this issue: any 
other aspects of read-only source trees are out of scope, and should be 
reported separately.

That said:

As for typeslots.inc: this shouldn't really be an issue for a released version 
of Python, since its tarball should include the generated file, and the 
timestamps should be in an order so that generation is unnecessary. This should 
be the case for all generated files that are also checked into Mercurial. For 
checkouts from Mercurial, you should do "make touch" after an update, as this 
will bring the timestamps in the right order.

It seems that graminit is missing from .hgtouch (in which case Trent's patch 
probably wouldn't have been necessary, except that it also fixes older 
branches). But that is again a different issue.

As for sysconfigdata: this really should be a separate issue. It's more 
difficult, since installation and packaging needs to pick up the file even if 
it's not in the source tree.

--

___
Python tracker 

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

[issue15824] mutable urlparse return type

[mastahyeti]

mastahyeti added the comment:

I can live with that, it just seems that ordinary item assignment is
more pythonic

On Thu, Aug 30, 2012 at 2:03 PM, R. David Murray  wrote:
>
> R. David Murray added the comment:
>
> Actually, Senthil is right.  What you want is the _replace method of 
> namedtuple to satisfy your use case.
>
> --
> resolution:  -> works for me
> stage:  -> committed/rejected
> status: open -> closed
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Ned Deily]

Ned Deily added the comment:

The sysconfigdata problem is already documented in two open issues: Issue14774 
and Issue15298.

--
nosy: +ned.deily

___
Python tracker 

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

[issue15824] mutable urlparse return type

[R. David Murray]

R. David Murray added the comment:

Not in this case.  We are treating the URL as an immutable object, so the 
Pythonic thing to do is create new object of the same type with the change 
applied.  Similar to "abcd".replace('a', 'z') returning a new string.

--

___
Python tracker 

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

[issue15824] mutable urlparse return type

[mastahyeti]

mastahyeti added the comment:

Hrmm. Okay. I concede.

On Thu, Aug 30, 2012 at 2:16 PM, R. David Murray  wrote:
>
> R. David Murray added the comment:
>
> Not in this case.  We are treating the URL as an immutable object, so the 
> Pythonic thing to do is create new object of the same type with the change 
> applied.  Similar to "abcd".replace('a', 'z') returning a new string.
>
> --
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Martin v . Löwis]

Martin v. Löwis added the comment:

As a further follow-up: the original code (in 67ed8a6905c3, by Neil Schemenauer 
from 2001), he explicitly changed GRAMMAR_C/H to refer to srcdir, claiming that 
errors from building them would be ignored.

In r87558, for which I can't find a subversion revsision for, Victor Stinner 
dropped the Makefile "-" marker, making the read-only case fail.

In reviewing the patch more, I think it is actually incorrect: it now generates 
the files into Include, but they aren't considered there since 
(builddir)/Include is not added to the -I options.

So the two options now are:
a) revert the patch, and restore Neil's original approach, or
b) add Include to the -I options, if srcdir is not "."

Reopening for consideration.

--
status: closed -> open

___
Python tracker 

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

[issue15824] mutable urlparse return type

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue15819] Unable to build Python out-of-tree when source tree is readonly.

[Martin v . Löwis]

Martin v. Löwis added the comment:

Reconsidering more: it would be desirable if even an out-of-source-tree 
compilation wouldn't require Python for bootstrapping; with the committed 
patch, it does since it will always run ASDLGEN.

If the source version of the generated files is fresh enough, they should just 
be copied to the destination.

I'm not quite sure how to achieve that with Make rules. This probably *is* a 
separate issue (which would become irrelevant if the patch here is reverted).

--

___
Python tracker 

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

[issue13992] Segfault in PyTrash_destroy_chain

[Antoine Pitrou]

Antoine Pitrou added the comment:

Can someone witnessing the problem try to apply the attached patch?

--
keywords: +patch
Added file: http://bugs.python.org/file27065/trashcan-2.7.patch

___
Python tracker 

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

[issue13992] Segfault in PyTrash_destroy_chain

[Antoine Pitrou]

Antoine Pitrou added the comment:

(for context about the patch, see my hypothesis at 
http://mail.python.org/pipermail/python-dev/2012-August/121533.html )

--

___
Python tracker 

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

[issue15825] Typo in OrderedDict docs

[ThiefMaster]

New submission from ThiefMaster:

"It is also straight-forward to create an ordered dictionary variant that the 
remembers the order the keys were last inserted."

The first "the" doesn't belong there.

--
assignee: docs@python
components: Documentation
messages: 169493
nosy: ThiefMaster, docs@python
priority: normal
severity: normal
status: open
title: Typo in OrderedDict docs
versions: Python 2.7, Python 3.2

___
Python tracker 

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

[issue14847] AttributeError: NoneType has no attribute 'utf_8_decode'

[Jason R. Coombs]

Jason R. Coombs added the comment:

Since my last comment, we've been running with a version of the wrapper 
(attached) around the main entry point to our application and it has completely 
eliminated the error. However, while the wrapper does report when a module 
deletion is requested, it is never triggered (we don't see the word "deletion" 
anywhere in our logs).

This result leads me to two findings:

1. Merely making a reference to sys.modules was sufficient to prevent the error.
2. Preventing deletion of 'encodings.*' modules is not sufficient (as 
apparently this doesn't happen in our code).

My next step is going to be to remove the wrapper, so the error exhibits itself 
again and we can prove that the issue is still present, and then to re-apply 
the wrapper, but this time only creating a reference to sys.modules (not 
actually replacing it).

--
Added file: http://bugs.python.org/file27066/wrapper.py

___
Python tracker 

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

[issue15822] Python 3.3 creates lib2to3 grammar in wrong order

[Ned Deily]

Ned Deily added the comment:

Can you give the steps to reproduce this issue?  Also, what platform and file 
system are in use?  I can guess what an underlying problem might be but I 
haven't been able to reproduce the failure myself.

--
nosy: +ned.deily

___
Python tracker 

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

[issue15826] Increased test coverage of test_glob.py

[Alessandro Moura]

New submission from Alessandro Moura:

Hi,

Here is a patch to increase test coverage of test_glob.py. I added tests where 
the glob patterns are of type bytes. The coverage (according to coverage.py) is 
now complete, except for what are clearly artefacts probably caused by the fact 
that glob is loaded before coverage measurements start (global statements are 
reported not covered but local ones are).

--
components: Tests
files: glob-cov-incr.patch
keywords: patch
messages: 169496
nosy: eng793
priority: normal
severity: normal
status: open
title: Increased test coverage of test_glob.py
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file27067/glob-cov-incr.patch

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Dag Sverre Seljebotn]

Dag Sverre Seljebotn added the comment:

It is perfectly possible for an object to export memory in a read-only way that 
may still change. Another object may have a writeable view:

x = obj.readonly_view
y = obj.writable_view
obj.move_to_next_image() # changes memory under x, y

So, hashing using tobytes() doesn't make any sense at all to me. A memoryview 
!= its contents.

You could compare memoryviews simply by comparing the Py_buffer structure, but 
that's going to be confusing for a lot of users. I would really prefer 
unhashable (+ if needed a method for comparing contents).

(FWIW, not sure how relevant this is; in NumPy, == does 

In [1]: np.array([1,2,3]) == np.array([1,3,3])
Out[1]: array([ True, False,  True], dtype=bool)

Cython will follow this behaviour for its "typed memory views", which is 
Cython's builting mechanism for PEP 3118 which is not quite the same as CPython 
"memoryview". But I understand that following this behaviour is probably out of 
the question for CPython.)

--
nosy: +Dag.Sverre.Seljebotn

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Dag Sverre Seljebotn]

Dag Sverre Seljebotn added the comment:

OK, I can understand the desire to make memoryviews be bytes-like objects 
(though to my mind, bytes is "frozen" in a very different way...)

If so, and it is deemed worth it, my suggestion is to add a new PyBUF_CONST 
flag to the buffer acquisition in that case (which can not be used together 
with PyBUF_WRITABLE). Given that flag, the exporter guarantees that the 
contents does not change (or fails to give away a buffer).

Perhaps it could be possible for hash() to try to re-acquire a const buffer, so 
that some buffers are hashable (by contents) and others not.

(I really think relying on buffers that are not writeable to be constant is 
dangerous. A readonly memoryview could for instance point straight to the live 
output of a webcam.)

--

___
Python tracker 

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

[issue15814] memoryview: equality-hash invariant

[Stefan Behnel]

Stefan Behnel added the comment:

To add on Dag's comments, this essentially means that any caching of the hash 
value is dangerous, unless it can be assured that the underlying buffer 
definitely has not changed in the meantime. There is no way for users to 
explicitly tell a memoryview to rehash itself, so putting it into one dict, 
then modifying the content, then putting it into another is a perfectly 
reasonable use case for users, but fails when the memory view caches its hash 
value.

As far as I can see it, any "obvious" fix for this creates a whole bath tub 
full of worms: updating views transitively, adding new APIs, supporting new 
buffer parameters, ...

--

___
Python tracker 

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

[issue15827] Use "ll" for PY_FORMAT_SIZE_T on Win64

[Stefan Behnel]

New submission from Stefan Behnel:

Formatting support for "lld"/"llu" was added (I think) in issue 7228, but the 
definition of PY_FORMAT_SIZE_T wasn't adapted. We are getting test output 
failures in Cython on Win64 when formatting error messages using the "Id" 
format, as defined by pyport.h:

"""
#ifndef PY_FORMAT_SIZE_T
#   if SIZEOF_SIZE_T == SIZEOF_INT && !defined(__APPLE__)
#   define PY_FORMAT_SIZE_T ""
#   elif SIZEOF_SIZE_T == SIZEOF_LONG
#   define PY_FORMAT_SIZE_T "l"
#   elif defined(MS_WINDOWS)
#   define PY_FORMAT_SIZE_T "I"
#   else
#   error "This platform's pyconfig.h needs to define PY_FORMAT_SIZE_T"
#   endif
#endif
"""

The "%Id" format is not being resolved in the error messages and shows up in 
the output instead.

NumPy uses "lld" when available, starting with Py2.7:

https://github.com/numpy/numpy/blob/master/numpy/core/include/numpy/npy_common.h#L66

Shouldn't PY_FORMAT_SIZE_T become "ll" on Win64 directly?

--
components: Interpreter Core
messages: 169500
nosy: scoder
priority: normal
severity: normal
status: open
title: Use "ll" for PY_FORMAT_SIZE_T on Win64
type: behavior
versions: Python 2.7, 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

[issue15827] Use "ll" for PY_FORMAT_SIZE_T on Win64

[Stefan Behnel]

Stefan Behnel added the comment:

I just saw that we were misusing PY_FORMAT_SIZE_T according to the 
documentation (reading that sometimes helps...). It is not supposed to be used 
with the Python formatting functions, only with low-level functions.

Closing, sorry for the noise.

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

[issue15822] Python 3.3 creates lib2to3 grammar in wrong order

[Tomi Pieviläinen]

Tomi Pieviläinen added the comment:

Platform: RHEL 6.3 x86_64.

0. (remove old python 3 install, though this doesn't change anything)
1. Unpack 3.3rc1 source, cd Python-3.3.0rc1/
2. ./configure; make
3. sudo make install
4. ls -ltc --full-time /usr/local/lib/python3.3/lib2to3/

This shows that Grammar.txt is just a tiny bit newer than the pickle.

To produce the SandboxViolation:

1. curl -O https://raw.github.com/pypa/virtualenv/master/virtualenv.py
2. python3.3 virtualenv.py my_new_env

or alternatively use distribute to install anything with the easy_install 
command.

--

___
Python tracker 

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

[issue15822] Python 3.3 creates lib2to3 grammar in wrong order

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis added the comment:

This issue can be easily reproduced on filesystems with nanosecond precision 
(e.g. ext4).

--

___
Python tracker 

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

[issue15822] Python 3.3 creates lib2to3 grammar in wrong order

[Tomi Pieviläinen]

Tomi Pieviläinen added the comment:

Ah, sorry, forgot to add that info. I also am running ext4.

--

___
Python tracker 

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

[issue15822] Python 3.3 creates lib2to3 grammar in wrong order

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis added the comment:

`make install DESTDIR=/some/temporary/path` can be used to avoid affecting 
installed version of Python.

--

___
Python tracker 

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