Serhiy Storchaka added the comment:
+ newline is '' or '\n', no translation takes place. If newline is
any\n
Non-escaped \n.
--
nosy: +storchaka
status: closed - open
___
Python tracker rep...@bugs.python.org
Georg Brandl added the comment:
Would be nice to be a bit more specific *where* that line comes from.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13119
___
Serhiy Storchaka added the comment:
Would be nice to be a bit more specific *where* that line comes from.
Modules/_io/textio.c, changesets 243ad1a6f638 and 083776adcacc.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13119
Serhiy Storchaka added the comment:
Oops, I got the wrong issue, sorry.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13119
___
New submission from Julien Palard:
This is accepted by browsers but raises an exception in HTMLParser :
from HTMLParser import HTMLParser
HTMLParser().feed(a onclick=foo({bar:42}); class=baz)
--
components: Library (Lib)
messages: 168352
nosy: JulienPalard
priority: normal
severity:
New submission from Robin Schreiber:
Changes proposed in PEP3121 have now been applied to the audioop module!
--
components: Extension Modules
files: audioop_pep3121_v0.patch
keywords: patch
messages: 168353
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP
New submission from Robin Schreiber:
Changes proposed in PEP3121 have now been applied to the binascii module!
--
components: Extension Modules
files: binascii_pep3121_v0.patch
keywords: patch
messages: 168354
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title:
New submission from Robin Schreiber:
Changes proposed in PEP3121 have now been applied to the fpectl module!
--
components: Extension Modules
files: fpectl_pep3121_v0.patch
keywords: patch
messages: 168355
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP
New submission from Arvin Moezzi:
I am not sure if this is the right way to do it but IMHO it would be great to
have a function decorator/transformer to make functions partial applicable
using functools.partial. Like
from functools import partial
class partial_applicable():
def
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the fpetest
module!
--
components: Extension Modules
files: fpetest_pep3121_v0.patch
keywords: patch
messages: 168357
nosy: Robin.Schreiber
priority: normal
severity: normal
status:
Arvin Moezzi added the comment:
Or maybe even
class partial_applicable():
def __call__(self, func):
def __wrapper(*args, **kvargs):
try:
return func(*args, **kvargs)
except TypeError:
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the itertools
module!
--
components: Extension Modules
files: itertools_pep3121-384_v0.patch
keywords: patch
messages: 168359
nosy: Robin.Schreiber, rhettinger
priority: normal
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the md5 module!
--
components: Extension Modules
files: md5_pep3121-384_v0.patch
keywords: patch
messages: 168360
nosy: Robin.Schreiber, gregory.p.smith
priority: normal
severity: normal
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the mmap module!
--
components: Extension Modules
files: mmap_pep3121-384_v0.patch
keywords: patch
messages: 168361
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the nis module!
--
components: Extension Modules
files: nis_pep3121_v0.patch
keywords: patch
messages: 168362
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title:
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the operator
module!
--
components: Extension Modules
files: operator_pep3121-384_v0.patch
keywords: patch
messages: 168363
nosy: Robin.Schreiber
priority: normal
severity: normal
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the parser
module!
--
components: Extension Modules
files: parser_pep3121-384_v0.patch
keywords: patch
messages: 168364
nosy: Robin.Schreiber
priority: normal
severity: normal
status:
Martin v. Löwis added the comment:
My current inclination is still to apply Victor's patch from #13072
(which changes array to export the appropriate integer typecodes for
'u' arrays) and otherwise punt on this for 3.3 and try to sort out
the mess for 3.4.
I think this would be the
Petri Lehtinen added the comment:
Tests are now passing on Windows, too. Closing.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11062
___
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the posix
module!
--
components: Extension Modules
files: posix_pep3121-384_v0.patch
keywords: patch
messages: 168367
nosy: Robin.Schreiber
priority: normal
severity: normal
status:
Nick Coghlan added the comment:
I wouldn't change the export formats used for the 'u' typecode at all in 3.4 -
I'd add new typecodes to array that match any new struct format characters and
are exported accordingly. 'u' would *never* become a formally defined struct
character, instead
Nick Coghlan added the comment:
Adding a link to #15625, which is discussing the other end of this issue
(whether or not memorview should support 'u' as a typecode).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13072
Martin v. Löwis added the comment:
I wouldn't change the export formats used for the 'u' typecode at
all in 3.4 - I'd add new typecodes to array that match any new
struct format characters and are exported accordingly. 'u' would
*never* become a formally defined struct character,
Nick Coghlan added the comment:
I guess the main alternative to deprecation that preserves the invariant you
describe would be to propagate the u == Py_UNICODE definition to memoryview.
Since we're trying to phase out Py_UNICODE, deprecation seems the more sensible
course.
Perhaps just a
Stefan Krah added the comment:
Martin v. Loewis rep...@bugs.python.org wrote:
I would be fine with deprecating the 'u' type arrays, acknowledging
that the Py_UNICODE element type is even more useless now than before.
If that is done, there is no point in fixing anything about it. If
it
Martin v. Löwis added the comment:
Based on the discussion in #15625, it seems that the consensus is to take no
action on the format codes in this issue for 3.3, and reconsider in 3.4, to
determine in what way the struct module should support Unicode.
Instead, the 'u' array code will be
Stefan Krah added the comment:
Well, apparently people do use 'u', see #15035.
--
nosy: +ronaldoussoren
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15625
___
Stefan Krah added the comment:
This one should be fixed by #13072. Could you check again?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15035
___
Nick Coghlan added the comment:
As Stefan noted, so long as Py_UNICODE is 16 bits in the Mac OS X builds, then
this should now be back to the 3.2 behaviour.
--
nosy: +ncoghlan
priority: low - high
___
Python tracker rep...@bugs.python.org
Martin v. Löwis added the comment:
#15035 indicates that there is a need for UCS-2 arrays, using 'u' arrays was
technically incorrect, since it is based on Py_UNICODE, whereas the API in
question uses UniChar (which apparently is a two-byte type).
--
Martin v. Löwis added the comment:
It's not back to the 3.2 behavior. In 3.3, Py_UNICODE is always equal to
wchar_t, which is a 4-byte type on Darwin. However, CFString is based on
UniChar, which is a 2-byte type.
That this worked in 3.2 was by accident - it would work only in narrow
builds.
Ronald Oussoren added the comment:
Py_UNICODE is an typedef for wchar_t and that type is 4 bytes long:
a.tobytes()
b'h\x00\x00\x00e\x00\x00\x00l\x00\x00\x00l\x00\x00\x00o\x00\x00\x00
\x00\x00\x00w\x00\x00\x00o\x00\x00\x00r\x00\x00\x00l\x00\x00\x00d\x00\x00\x00'
a = array.array('u', 'bar')
Stefan Krah added the comment:
Martin v. L??wis rep...@bugs.python.org wrote:
#15035 indicates that there is a need for UCS-2 arrays, using 'u' arrays was
technically incorrect, since it is based on Py_UNICODE, whereas the API in
question uses UniChar (which apparently is a two-byte type).
R. David Murray added the comment:
This is fixed in more recent versions of Python (2.7, 3.2+).
--
nosy: +r.david.murray
resolution: - out of date
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
R. David Murray added the comment:
YAGNI, is what I think. Or if you do need it, put it in your application. (To
tell you the truth, it just looks confusing to me...it strikes me as too
magical.)
Regardless, this is more of a python-ideas kind of issue, so I suggest raising
it there if you
Daniel Ellis added the comment:
Made changes in structure in 2.7 branch to match 3.3 based on Eli's comments.
Updated input prompt in examples per Ezio's review (though the default branch
will still need this update).
--
Added file:
New submission from Björn Dahlgren:
Hi, I hope this is not a false positive but I cannot help thinking this is a
bug, consider:
Python 2.7.3 (default, Aug 1 2012, 05:14:39)
[GCC 4.6.3] on linux2
Type help, copyright, credits or license for more information.
-3.2**0
-1.0
sign=lambda x: x**0
Arvin Moezzi added the comment:
Thanks for your feedback.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15683
___
___
Python-bugs-list mailing
R. David Murray added the comment:
Thanks for your suggestion, even though I'm rejecting the suggestion as a bug
tracker issue. (I should have said that at the start of my answer.)
--
___
Python tracker rep...@bugs.python.org
Serhiy Storchaka added the comment:
-3.2**0 == -(3.2**0)
(-3.2)**0
1.0
--
nosy: +storchaka
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15692
R. David Murray added the comment:
I think it probably should be filed with sphinx instead, rather than also.
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15693
___
Roundup Robot added the comment:
New changeset 4307b985209b by Richard Oudkerk in branch 'default':
Issue #14669: Fix pickling of connections and sockets on MacOSX
http://hg.python.org/cpython/rev/4307b985209b
--
___
Python tracker
New submission from Chris Jerdonek:
It would be nice if hovering over the right side of the header to a glossary
entry would expose a link in the same way that it does for function
definitions, etc.
http://docs.python.org/dev/glossary.html#glossary
Otherwise, there doesn't seem to be a
New submission from Chris Jerdonek:
It would be nice if the first sentence of the documentation for the open()
built-in function:
Open file and return a corresponding stream. If the file cannot be opened, an
OSError is raised.
http://docs.python.org/dev/library/functions.html#open
linked to
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
keywords: +easy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15694
___
___
Chris Jerdonek added the comment:
Do we pin the version of Sphinx that we use to generate the documentation? If
Sphinx fixes the issue, would we need to make a corresponding change here to
reflect the fix?
--
___
Python tracker
R. David Murray added the comment:
We do pin it, but we generally have no problem with upgrading. I think we
generally upgrade it exactly when there is a new Sphinx feature we want for our
docs :) We don't maintain local patches to Sphinx (though we do have code that
is specific to our
Chris Jerdonek added the comment:
I think we generally upgrade it exactly when there is a new Sphinx feature we
want for our docs :)
:) Would the appropriate way to handle it be then to create an issue to
upgrade Sphinx when XXX issue is resolved and link to the corresponding
Sphinx
R. David Murray added the comment:
Well, I think it depends on what we consider the priority of the issue. So, I
personally would count this one as low, and would be happy that it gets fixed
whenever we happen to upgrade to a version of Sphinx that fixes it. If it is
an issue we consider
Petri Lehtinen added the comment:
Any reason why this hasn't been backported to 3.2 or 2.7?
--
nosy: +petri.lehtinen
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6484
___
R. David Murray added the comment:
There are divided opinions about the advisability of backporting tests that are
not part of a bug fix. In this case, there is also the fact that it includes a
test that fails without a bug fix that was not backported.
--
Chris Jerdonek added the comment:
I created a Sphinx issue for this here:
https://bitbucket.org/birkenfeld/sphinx/issue/996/expose-glossary-entry-link-on-hover
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15693
New submission from Serhiy Storchaka:
Here is a patch that implements correct __sizeof__ for StgDict (a dictionary
subclass used in ctypes).
There are no tests because I don't know how to create and use StgDict. So I'm
not sure that the code works correctly. Please help me with tests.
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file26855/stgdict_sizeof-3.2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15695
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
stage: patch review - test needed
Added file: http://bugs.python.org/file26856/stgdict_sizeof-2.7.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15695
Chris Jerdonek added the comment:
I created a Sphinx issue for this here:
https://bitbucket.org/birkenfeld/sphinx/issue/997/index-targets-not-getting-created-in
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15455
Chris Jerdonek added the comment:
Attaching patch. I also added two index entries for file object and made a
couple wording adjustments to the intro paragraph of the io module.
--
keywords: +patch
stage: - patch review
versions: +Python 3.2
Added file:
New submission from Serhiy Storchaka:
Here is a patch that implements correct __sizeof__ for mmap under Windows.
I have not tested it because it is Windows-only issue. Please test it.
--
components: Library (Lib), Windows
files: mmap_sizeof-3.x.patch
keywords: patch
messages: 168402
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file26859/mmap_sizeof-2.7.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15696
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
stage: - patch review
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15696
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15625
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15035
___
New submission from Robin Schreiber:
Changes proposed in PEP3121 have now been applied to the pwd module!
--
components: Extension Modules
files: pwd_pep3121_v0.patch
keywords: patch
messages: 168403
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the pyexpat
module!
--
components: Extension Modules
files: pyexpat_pep3121-384_v0.patch
keywords: patch
messages: 168404
nosy: Robin.Schreiber
priority: normal
severity: normal
status:
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the readline
module!
--
components: Extension Modules
files: readline_pep3121-384_v0.patch
keywords: patch
messages: 168405
nosy: Robin.Schreiber
priority: normal
severity: normal
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the resource
module!
--
components: Extension Modules
files: resource_pep3121-384_v0.patch
keywords: patch
messages: 168406
nosy: Robin.Schreiber
priority: normal
severity: normal
New submission from Jody McIntyre:
I attempted to connect to a site using urllib2 and digest authentication and it
raised an HTTPError (due to an incorrect username and password, which is
expected). I attempted to run the info() method of the HTTPError to get more
information, but it failed
New submission from James Hutchison:
Following code deadlocks on Windows 7 64-bit, Python 3.2.3
If you have a pool issue a map operation over an empty iterable then try to
join later, it will deadlock. If there is no map operation or blah in the code
below isn't empty, it does not deadlock
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15702
___
___
Python-bugs-list mailing list
Andrew Svetlov added the comment:
Thank you, Petri.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11062
___
___
Python-bugs-list mailing list
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the select
module!
--
components: Extension Modules
files: select_pep3121-384_v0.patch
keywords: patch
messages: 168410
nosy: Robin.Schreiber
priority: normal
severity: normal
status:
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the sha1 module!
--
components: Extension Modules
files: sha1_pep3121-384_v0.patch
keywords: patch
messages: 168411
nosy: Robin.Schreiber, gregory.p.smith
priority: normal
severity:
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6696
___
___
Python-bugs-list
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the sha256
module!
--
components: Extension Modules
files: sha256_pep3121-384_v0.patch
keywords: patch
messages: 168412
nosy: Robin.Schreiber, gregory.p.smith
priority: normal
severity:
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the sha512
module!
--
components: Extension Modules
files: sha512_pep3121-384_v0.patch
keywords: patch
messages: 168413
nosy: Robin.Schreiber, gregory.p.smith
priority: normal
severity:
Jeff Knupp added the comment:
This is a duplicate of http://bugs.python.org/issue12157, which was fixed.
--
nosy: +Jeff.Knupp
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15702
___
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the signal
module!
--
components: Extension Modules
files: signal_pep3121-384_v0.patch
keywords: patch
messages: 168415
nosy: Robin.Schreiber
priority: normal
severity: normal
status:
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the socket
module!
--
components: Extension Modules
files: socket_pep3121-384_v0.patch
keywords: patch
messages: 168416
nosy: Robin.Schreiber
priority: normal
severity: normal
status:
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the termios
module!
--
components: Extension Modules
files: termios_pep3121-384_v0.patch
keywords: patch
messages: 168417
nosy: Robin.Schreiber
priority: normal
severity: normal
status:
New submission from Tobin Baker:
I'm using a 3rd-party library (ESAPI) which defines a log level as the literal
-2**31. This worked fine until I upgraded to Python 2.7.3, which, unlike all
previous versions of Python, coerces that literal to long rather than int. The
following code in the
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +vinay.sajip
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15710
___
___
Python-bugs-list
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the time module!
--
components: Extension Modules
files: time_pep3121-384_v0.patch
keywords: patch
messages: 168419
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the unicodedata
module!
--
components: Extension Modules
files: unicodedate_pep3121-384_v0.patch
keywords: patch
messages: 168420
nosy: Robin.Schreiber, effbot, lemburg, loewis
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the zipimport
module!
--
components: Extension Modules
files: zipimport_pep3121-384_v0.patch
keywords: patch
messages: 168421
nosy: Robin.Schreiber
priority: normal
severity: normal
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the grp module!
--
components: Extension Modules
files: grp_pep3121-384_v0.patch
keywords: patch
messages: 168422
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
New submission from Simon Feltman:
This came up while trying to build pygobject with Python 3.3. The problem is
there are some erroneous imports in the fromlist with these bindings that can
easily be fixed. But it is a behavioral change so I just wanted to raise
awareness if it is not already
Changes by Simon Feltman s.felt...@gmail.com:
--
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15715
___
___
Python-bugs-list
Eric Snow added the comment:
While this is a regression, 3.3 definitely puts an increased emphasis on using
importlib.import_module() instead of builtins.__import__(). Any reason why
import_module() isn't used?
As to the regression, while the current behavior makes more sense, it is
Simon Feltman added the comment:
I think pygobject still supports Python 2.5 which it look like importlib is
available.
I've submitted a patch to pygobject which will work regardless of if this
regression is fixed or not: https://bugzilla.gnome.org/show_bug.cgi?id=682051
--
Simon Feltman added the comment:
Should have been ...Python 2.5 which it looks like importlib is NOT available.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15715
___
Antoine Pitrou added the comment:
Unless it is difficult to fix, I think this regression should be addressed
before 3.3 final. Georg?
--
components: +Interpreter Core, Library (Lib) -None
nosy: +pitrou
priority: normal - release blocker
stage: - needs patch
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15715
___
___
Python-bugs-list
Gregory P. Smith added the comment:
I'd also like a command line flag to override PYTHONPATH (which could also be
used in combination with -E so that you could still set the PYTHONPATH while
ignoring everything else). I'll file a separate feature request for that.
--
nosy:
New submission from Gregory P. Smith:
I'd like a command line flag to override PYTHONPATH. It could also be used in
combination with -E so that you could still set the PYTHONPATH while ignoring
everything else from the environment.
--
messages: 168429
nosy: gregory.p.smith
priority:
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15716
___
___
Python-bugs-list
R. David Murray added the comment:
Chris, if Nick is too busy to reply right now and you want to move this along,
you could write some tests (not necessarily for inclusion in the test suite) to
confirm that the doc you are adding is correct. I don't know enough about
generators to comment
Petri Lehtinen added the comment:
No reply in two years, closing.
--
nosy: +petri.lehtinen
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4253
___
Eric Snow added the comment:
The failure output with -v:
...
# /home/esnow/projects/cpython/Lib/http/__pycache__/__init__.cpython-33.pyc
matches /home/esnow/projects/cpython/Lib/http/__init__.py
# code object from
/home/esnow/projects/cpython/Lib/http/__pycache__/__init__.cpython-33.pyc
Eric Snow added the comment:
Here's a simple patch the allows bogus names in the fromlist. I'm going to
verify that this matches the 3.2 semantics, which may not be so cut-and-dry.
--
keywords: +patch
Added file: http://bugs.python.org/file26876/issue15715.diff
99 matches
Mail list logo
