[issue8904] quick example how to fix docs

[anatoly techtonik]

anatoly techtonik  added the comment:

On Mon, Jun 7, 2010 at 1:26 AM, Éric Araujo  wrote:
>
> Would the addition of a link to http://www.python.org/dev/patches/ address 
> your request?

No. It is not quick. It short only for an experienced developer. The
example (or documentation HowTo) should be user based with explanation
how to checkout, compile and test the changes.

--

___
Python tracker 

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

[issue8828] Atomic function to rename a file

[anatoly techtonik]

anatoly techtonik  added the comment:

Atomic file renames are reimplemented by:
1. Mercurial
2. Trac
3. Dulwich (aka HgGit)

and essential for many other projects out there, so this should be in standard 
library. Atomic renames depend on filesystem more that on the OS.

--
nosy: +techtonik

___
Python tracker 

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

[issue7989] Transition time/datetime C modules to Python

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky  added the comment:
> 
> As far as I remember, the datetime module started as a pure python module and 
> was reimplemented in C around year 2003 or so.  One of the important 
> additions at that time was the C API to datetime functionality.  I am afraid 
> that with the _timemodule.c/timemodule.py split there will be more an more 
> functionality that is awkward to access from C API.

That's correct, though the main reason for rewriting the module in
C was to gain performance - this is essential for basic types like
date/time types.

-1 on undoing the C rewrite.

It would be much better to spell out the problems you mention and
provide patches to implement solutions for them.

--
nosy: +lemburg

___
Python tracker 

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

[issue8929] wininst: msvcr90 dependency in x64 build

[Christian Boos]

Christian Boos  added the comment:

I did a mistake and downloaded an older installer, sorry for the trouble this 
caused.

The actual Python 2.6.5 (x64) has wininst-9.0.exe and wininst-9.0-amd64.exe 
built statically as expected.

--
nosy: +cboos

___
Python tracker 

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

[issue8929] wininst: msvcr90 dependency in x64 build

[Martin v . Löwis]

Changes by Martin v. Löwis :


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

[issue8848] Deprecate or remove "U" and "U#" formats of Py_BuildValue()

[Walter Dörwald]

Walter Dörwald  added the comment:

Yes, I think you should apply the patch.

--

___
Python tracker 

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

[issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum recursion depth exceeded in cmp

[Mads Kiilerich]

Mads Kiilerich  added the comment:

FYI:
The regression was introduced in 2.6.5 with issue3819 .

This also causes problems with Mercurial pushing to google code - see 
http://mercurial.selenic.com/bts/issue2179 . 

IIRC google code redirects to an url which then in turn requests 
authentication. I'm not sure how that will work with a retry count of 1. The 
funny and inconsistent thing is that it apparently would work if they replied 
403 instead of 401. "durin42" from google/mercurial knows the details.

(It seems suspicious to me that there are code paths where the retry counter is 
reset. Doesn't that mean that a remote server will be able to cause endless 
recursion? Shouldn't there be some kind of hard upper limit on the number of 
retries?)

--
nosy: +kiilerix

___
Python tracker 

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

[issue8897] sunau bytes / str TypeError in Py3k

[Thomas Jollans]

Thomas Jollans  added the comment:

Attached is a patch against the current py3k trunk that fixes this. (as far as 
I can tell)

--
keywords: +patch
Added file: http://bugs.python.org/file17580/sunau-bytes.diff

___
Python tracker 

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

[issue8897] sunau bytes / str TypeError in Py3k

[STINNER Victor]

STINNER Victor  added the comment:

Can you add a test?

--
nosy: +haypo

___
Python tracker 

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

[issue8828] Atomic function to rename a file

[STINNER Victor]

STINNER Victor  added the comment:

Implementation of "atomic" rename() for Windows in Mercurial:
http://selenic.com/repo/hg/file/tip/mercurial/windows.py
(search for "def rename")

--

___
Python tracker 

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

[issue7989] Transition time/datetime C modules to Python

[Daniel Urban]

Changes by Daniel Urban :


--
nosy: +durban

___
Python tracker 

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

[issue8904] quick example how to fix docs

[Brian Curtin]

Brian Curtin  added the comment:

I think what you are suggesting is outside of the scope of that document -- it 
appears that the page intends to be quick and strictly focused on reporting 
bugs, not fixing them.

--
nosy: +brian.curtin
status: open -> pending

___
Python tracker 

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

[issue8875] XML-RPC improvement is described twice.

[A.M. Kuchling]

A.M. Kuchling  added the comment:

Fixed in rev81801.  Thanks for your report!

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

[issue8932] test_capi fails --without-threads

[Stefan Krah]

New submission from Stefan Krah :

test_capi fails when compiled --without-threads:

test test_capi failed -- Traceback (most recent call last):
  File 
"/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_capi.py", line 
49, in test_no_FatalError_infinite_loop
b'Fatal Python error:'
AssertionError: b'Traceback (most recent call last):\n  File "", line 
1, in \nSystemError: error return without exception set\n[34135 refs]' 
!= b'Fatal Python error: PyThreadState_Get: no current thread'

Re-running test test_capi in verbose mode
test_instancemethod (test.test_capi.CAPITest) ... ok
test_no_FatalError_infinite_loop (test.test_capi.CAPITest) ... FAIL

==
FAIL: test_no_FatalError_infinite_loop (test.test_capi.CAPITest)
--
Traceback (most recent call last):
  File 
"/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_capi.py", line 
49, in test_no_FatalError_infinite_loop
b'Fatal Python error:'
AssertionError: b'Traceback (most recent call last):\n  File "", line 
1, in \nSystemError: error return without exception set\n[34135 refs]' 
!= b'Fatal Python error: PyThreadState_Get: no current thread'

--
Ran 2 tests in 0.635s

FAILED (failures=1)
test test_capi failed -- Traceback (most recent call last):
  File 
"/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_capi.py", line 
49, in test_no_FatalError_infinite_loop
b'Fatal Python error:'
AssertionError: b'Traceback (most recent call last):\n  File "", line 
1, in \nSystemError: error return without exception set\n[34135 refs]' 
!= b'Fatal Python error: PyThreadState_Get: no current thread'

--
components: Tests
keywords: buildbot
messages: 107267
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_capi fails --without-threads
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

[issue8933] Invalid detection of metadata version

[Benjamin Liles]

New submission from Benjamin Liles :

The detection for metadata version does not follow what is specified in PEP 241 
and PEP 314.

Specifically, the following fields are being sent as version 1.0 when they are 
not allowed as per PEP 241:

* Classifier
* Download-URL

--
assignee: tarek
components: Distutils
messages: 107268
nosy: benliles, tarek
priority: normal
severity: normal
status: open
title: Invalid detection of metadata version
type: behavior
versions: Python 2.5, Python 2.6

___
Python tracker 

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

[issue8933] Invalid detection of metadata version

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +merwok

___
Python tracker 

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

[issue8828] Atomic function to rename a file

[anatoly techtonik]

anatoly techtonik  added the comment:

Dulwich bug discussion (closed) - 
https://bugs.edge.launchpad.net/dulwich/+bug/557585

Trac implementation - 
http://trac.edgewall.org/browser/trunk/trac/util/__init__.py?#L82

Stackoverflow - 
http://stackoverflow.com/questions/167414/is-an-atomic-file-rename-with-overwrite-possible-on-windows

--

___
Python tracker 

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

[issue8910] Write a text file explaining why Lib/test/data exists

[Éric Araujo]

Éric Araujo  added the comment:

Attaching a proposal.

I think the component is a grey area between tests and documentation, so I’d be 
for including this file in all four branches.

--
keywords: +needs review, patch
nosy: +d...@python, merwok
Added file: http://bugs.python.org/file17581/README

___
Python tracker 

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

[issue8897] sunau bytes / str TypeError in Py3k

[Thomas Jollans]

Thomas Jollans  added the comment:

test case for sunau, as requested. Loosely based on test_wave.

--
Added file: http://bugs.python.org/file17582/sunau-test.diff

___
Python tracker 

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

[issue4769] b64decode should accept strings or bytes

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +merwok

___
Python tracker 

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

[issue7989] Transition time/datetime C modules to Python

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

For the datetime module there are also a few more subtle issues that would make 
it difficult to make a hybrid C/Python implementation.  The problem is that 
unlike the time module where most of the functionality is implemented in module 
level functions, datetime functionality is entirely in class methods.

One may suggest to use inheritance and derive datetime classes from those 
implemented in _datetime.c, but this will not work because for example datetime 
+ timedelta will return a _datetime class unless __add__ is overridden in 
Python.  There is another even less obvious issue with inheriting from datetime 
classes: see issue #5516.

Therefore, it looks like there are only two choices:

1. Replicate all functionality in both _datetime.c and datetime.py and thus 
double the cost of implementing new features in CPython. (OK, maybe not double 
because Python development is easier than C, but increase instead of decrease.)

2. Incur a performance penalty in every method because every C call wil have to 
be wrapped in Python.

Another -1 from me.

--

___
Python tracker 

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

[issue7989] Transition time/datetime C modules to Python

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


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

[issue8719] buildbot: segfault on FreeBSD (signal 11)

[Stefan Krah]

Stefan Krah  added the comment:

I ran a test --without-threads: test_runpy and test_exceptions passed,
test_sys was not reached:


test_sqlite
Fatal error 'Cannot allocate red zone for initial thread' at line 384 in file 
/usr/src/lib/libthr/thread/thr_init.c (errno = 12)
*** Signal 6


No Signal 11. I suspect threads (again).

Would it be a good idea to run the FreeBSD bots --without-threads?

--
nosy: +db3l, skrah

___
Python tracker 

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

[issue8934] aifc should use str instead of bytes (wave, sunau compatibility)

[Thomas Jollans]

New submission from Thomas Jollans :

aifc getcomptype() and setcomptype() use bytes while the corresponding methods 
in the sunau and wave modules use str (b'NONE', b'ULAW' vs 'NONE', 'ULAW'). 
This means that programmers wanting simple format-agnostic audio file output 
will have to special-case aifc. This was not necessary in Python 2.x, where all 
three modules used str (obviously). IMHO, there is no reason for this 
incompatibility.

The solution I propose is to change aifc to use unicode str for "information" 
strings and bytes for raw data only, like the other two modules. This is, the 
way I see it, the most sensible behaviour.

I'm attaching a patch that does just this: it changes aifc to use str for all 
(non-data) strings: comptype, compname, and markers. I've also changed the 
testcase accordingly.

The problem is, obviously, that this could break existing code. I doubt that it 
would break a lot of code since:
 - not that many people use aifc anyway (I think), and py3k is still
   young
 - py3k code that's out there now would most likely handle both
   scenarios anyway to account for the wave and sunau modules
 - setcomptype() would still accept bytes.

On the other hand, it would, as I said, simplify writing format-agnostic code. 
Special-casing any module wouldn't have been necessary with Python 2, why 
should Python 3 be any different?

There, I've made my case. Georg, I put you on the nosy list because of
  [svn r64023] Remove cl usage from aifc and use bytes throughout.
You, apparently, made the decision I'm arguing should be reverted, if indeed 
anyone consciously made it at all.

If this is applied, it would have to be properly documented, of course.

--
components: Library (Lib)
files: aifc_use_str.diff
keywords: patch
messages: 107274
nosy: georg.brandl, tjollans
priority: normal
severity: normal
status: open
title: aifc should use str instead of bytes (wave, sunau compatibility)
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17583/aifc_use_str.diff

___
Python tracker 

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

[issue7989] Transition time/datetime C modules to Python

[Brian Curtin]

Brian Curtin  added the comment:

It seems like this might not be worth it or a good idea, and I have no strong 
feeling for this being done. Feel free to close/reject this one.

--

___
Python tracker 

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

[issue8934] aifc should use str instead of bytes (wave, sunau compatibility)

[STINNER Victor]

Changes by STINNER Victor :


--
components: +Unicode
nosy: +haypo

___
Python tracker 

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

[issue8848] Deprecate or remove "U" and "U#" formats of Py_BuildValue()

[STINNER Victor]

STINNER Victor  added the comment:

Commited to py3k (r81807), blocked in 3.1 (r81808).

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

[issue8905] difflib should accept arbitrary line iterators

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue8919] python should read ~/.pythonrc.py by default

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue1982] Feature: extend strftime to accept milliseconds

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue8897] sunau bytes / str TypeError in Py3k

[STINNER Victor]

STINNER Victor  added the comment:

> test case for sunau, as requested. Loosely based on test_wave.

Ok great. Commited to py3k (r81809) and 3.1 (r81810).

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

[issue8934] aifc should use str instead of bytes (wave, sunau compatibility)

[Thomas Jollans]

Thomas Jollans  added the comment:

tentative documentation patch uploaded

--
Added file: http://bugs.python.org/file17584/aifc_str_doc.diff

___
Python tracker 

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

[issue5094] datetime lacks concrete tzinfo impl. for UTC

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Readying the patch for commit.  Added documentation, tests and implementation 
of fromutc() method that does not need a dst().

--
resolution:  -> accepted
Added file: http://bugs.python.org/file17585/issue5094d.diff

___
Python tracker 

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

[issue8922] Improve encoding shortcuts in PyUnicode_AsEncodedString()

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
> New submission from STINNER Victor :
> 
> PyUnicode_Decode() and PyUnicode_AsEncodedString() calls directly builtin 
> decoders/encoders for some known encodings (eg. "utf-8"), instead of using 
> the slow path (call PyCodec_Decode() / PyCodec_Encode()). 
> 
> PyUnicode_Decode() does normalize the encoding name: convert to lower and 
> replace "_" by "-", as normalizestring() does. But 
> PyUnicode_AsEncodedString() doesn't normalize the encoding name, it just use 
> strcmp(). PyUnicode_Decode() has a shortcut for ISO-8859-1, whereas 
> PyUnicode_AsEncodedString() doesn't (only for "latin-1").
> 
> Attached patch creates a subfunction (static) normalize_encoding(), use it in 
> PyUnicode_Decode() and PyUnicode_AsEncodedString(), and adds a shortcut for 
> ISO-8859-1 to PyUnicode_AsEncodedString().

The normalization in PyUnicode_Decode() must have been added to
Python3 only. It is not present in Python2.

I'm not sure whether it's a good idea to extend this further:
the shortcuts were meant for Python internal use only. Python
itself and it's stdlib should only use the shortcut names
for the resp. special encodings and no variants.

Dealing with variants and normalization is left to the encodings
package and its alias machinery.

Since the Python stdlib and the core already mostly use
the shortcut names, adding normalization won't buy us much.

Note that your change has also made it impossible for the
compiler to do loop unrolling - there's not upper limit
on the size of lower anymore.

In terms of coding style, "static" should go on a separate line.

--
nosy: +lemburg

___
Python tracker 

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

[issue8925] Improve c-api/arg.rst: use "bytes" or "str" types instead of "string"

[STINNER Victor]

STINNER Victor  added the comment:

Commited to 3.2 (r81811) and 3.1 (r81812). The final patch adds also links to 
tuple, list, dict, float, complex and int. Replace also long by int (long 
doesn't exist anymore in Python3).

@merwok: Please open a new issue if you would like to improve the documentation 
about the buffer protocol.

--

___
Python tracker 

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

[issue8925] Improve c-api/arg.rst: use "bytes" or "str" types instead of "string"

[STINNER Victor]

Changes by STINNER Victor :


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

[issue8923] Remove unused "errors" argument from _PyUnicode_AsDefaultEncodedString()

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
> New submission from STINNER Victor :
> 
> _PyUnicode_AsDefaultEncodedString() has two arguments: unicode (input string) 
> and errors. If errors is not NULL, it calls Py_FatalError()!
> 
> The argument is useful: all functions call it with errors=NULL.
> 
> Attached patch removes the argument.

While it's an internal API, it's still public and we cannot
just remove the extra argument - we're in stable branch mode.

Since Python3 fixes the UTF-8 default encoding, it's better
to enhance PyUnicode_AsUTF8String() to cache the UTF-8
string in the Unicode object or simply return it directly
and then replace all uses of _PyUnicode_AsDefaultEncodedString()
with PyUnicode_AsUTF8String().

We should phase out use of _PyUnicode_AsDefaultEncodedString()
as well as the whole default encoding terminology altogether.

Please also add a documentation patch and a NEWS entry.

--
nosy: +lemburg
title: Remove unused "errors" argument from _PyUnicode_AsDefaultEncodedString() 
-> Remove unused "errors" argument from _PyUnicode_AsDefaultEncodedString()

___
Python tracker 

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

[issue8925] Improve c-api/arg.rst: use "bytes" or "str" types instead of "string"

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
> New submission from STINNER Victor :
> 
> http://docs.python.org/py3k/c-api/arg.html is unclear about what is a 
> "string".
> 
> Attached patch:
>  - Use directly bytes, bytearray and str types
>  - Replace "default encoding" by "``'utf-8'`` encoding"
>  - Add bytes and/or bytearray to "... buffer compatible object" because it's 
> not easy to understand what is a buffer compatible object, especially because 
> there are different kind of buffer objects: read-only, read-write, pinned, 
> etc.
>  - Fix reST syntax ("..note ::")
>  - Fix "es", "es#", "et" and "et#" formats: they doesn't accept "character 
> buffer compatible object" (can someone double check that?)

The character buffer concept is (unfortunately) gone in Python3.

There's no way for a buffer compatible object to tell the
arg parser that it is storing text data. Perhaps we can add something
like that back via the Py_buffer flags for getting buffers.

--
nosy: +lemburg
title: Improve c-api/arg.rst: use "bytes" or "str" types instead of "string" -> 
Improve c-api/arg.rst: use "bytes" or "str" types instead   of "string"

___
Python tracker 

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

[issue8839] PyArg_ParseTuple(): remove "t# format

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
> New version of the patch:
>  - charbuffer_encode() uses y* instead of y# format to accept modifiable 
> buffer objects (eg. bytearray)
>  - Improve the documentation about the change
> 
> @lemburg: So, do you agree with my patch?

No, because y*/y# are not correct replacements for t#. They don't
accept Unicode objects.

t# was meant to provide access to text data, so replacing it with a
parser code that is meant for binary data is not correct. The
closes Python3 gets to t# from Python2 is s# or s*, so please use
those in the NEWS entry and s* in charbuffer_encode().

--

___
Python tracker 

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

[issue8922] Improve encoding shortcuts in PyUnicode_AsEncodedString()

[STINNER Victor]

STINNER Victor  added the comment:

> the shortcuts were meant for Python internal use only

str.encode() calls PyUnicode_AsEncodedString() and bytes.decode() calls 
PyUnicode_Decode(), so it is not for internal use only. Eg. 
"text".encode("ASCII") doesn't use the fastpath.

--

___
Python tracker 

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

[issue8922] Improve encoding shortcuts in PyUnicode_AsEncodedString()

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
>> the shortcuts were meant for Python internal use only
> 
> str.encode() calls PyUnicode_AsEncodedString() and bytes.decode() calls 
> PyUnicode_Decode(), so it is not for internal use only. Eg. 
> "text".encode("ASCII") doesn't use the fastpath.

Right. As I said: the *shortcuts* are meant for internal use
only. External code should not rely on them, but can, of course,
use those canonical names as well.

Note that these shortcut bypass the codec registry logic. Codec
search functions cannot redirect these shortcuts to their
own implementations, so we have to be careful about adding more
such shortcuts.

--

___
Python tracker 

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

[issue8922] Improve encoding shortcuts in PyUnicode_AsEncodedString()

[STINNER Victor]

STINNER Victor  added the comment:

> Note that these shortcut bypass the codec registry logic.

Yes, but it's already the case without my patch. I don't think that it's really 
useful to override latin1, utf-8, utf-16, utf-32 or mbcs. I prefer a faster 
Python :-) 

> we have to be careful about adding more such shortcuts.

I just want to add a shortcut for ISO-8859-1.

--

___
Python tracker 

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

[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()

[STINNER Victor]

STINNER Victor  added the comment:

MAL agreed to remove "t#" parsing format (#8839), whereas charbuffer_encode() 
main goal was to offer "t#" parsing format to Python object space. 
charbuffer_encode() is now useless in Python3. bytes() accepts any buffer 
object (read-only and read/write buffer), so readbuffer_encode() became useless 
in Python3.

readbuffer_encode() and charbuffer_encode() were never documented, and are not 
used by any 3rd party library.

Can we remove these two functions?

--

___
Python tracker 

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

[issue8925] Improve c-api/arg.rst: use "bytes" or "str" types instead of "string"

[STINNER Victor]

STINNER Victor  added the comment:

> There's no way for a buffer compatible object to tell the
> arg parser that it is storing text data.

I think that the buffer protocol targets byte strings/arrays, and that unicode 
type should be enough.

If applications have to exchange text data, they use utf8, which is a byte 
string. I don't see the use case. Open a discussion on python-dev if you would 
like to continue the discussion because this issue is closed.

--

___
Python tracker 

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

[issue5094] datetime lacks concrete tzinfo impl. for UTC

[Daniel Urban]

Daniel Urban  added the comment:

In Doc/library/datetime.rst, in the documentation of datetime.utcnow this part: 
".. versionchanged:: 2.7" probably should be ".. versionchanged:: 3.2".

--

___
Python tracker 

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

[issue5094] datetime lacks concrete tzinfo impl. for UTC

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Thanks, Daniel.  This was a leftover from the previous patch.  The latest patch 
does not actually change utcnow().  Instead the users should call 
datetime.now(timezone.utc). Fixed in issue5094d1.diff.

--
Added file: http://bugs.python.org/file17586/issue5094d1.diff

___
Python tracker 

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

[issue7989] Transition time/datetime C modules to Python

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Brett Cannon wrote in a comment (msg106498) on another issue:

"""
The stated long-term goal of the stdlib is to minimize the C extension modules 
to only those that have to be written in C (modules can still have performance 
enhancing extension back-ends). Since datetime does not meet that requirement 
it's not a matter of "if" but "when" datetime will get a pure Python version 
and use the extension code only for performance.
"""

I'll keep this open for a while to give Brett and others a chance to respond to 
opposition.

--
nosy: +brett.cannon
priority: normal -> low
type: behavior -> feature request

___
Python tracker 

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

[issue7989] Transition time/datetime C modules to Python

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Also, my opposition is only to splitting datetime.  While I am not against 
splitting the time module, I believe it should be phased out eventually and 
posix compatibility portion folded into posix module.

--

___
Python tracker 

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

[issue8935] Syntax error in os.py

[Stan Klein]

New submission from Stan Klein :

I got the following traceback on an "import os" statement:


Traceback (most recent call last):
  File "setup.py", line 53, in ?
import traceback
  File "/usr/lib/python2.6/traceback.py", line 3, in ?
import linecache
  File "/usr/lib/python2.6/linecache.py", line 9, in ?
import os
  File "/usr/lib/python2.6/os.py", line 758
bs = b""
   ^
SyntaxError: invalid syntax

>From looking at 2.4, the fix is probably bs=""

--
components: Library (Lib)
messages: 107294
nosy: sklein
priority: normal
severity: normal
status: open
title: Syntax error in os.py
type: crash
versions: Python 2.6

___
Python tracker 

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

[issue7989] Transition time/datetime C modules to Python

[Brett Cannon]

Brett Cannon  added the comment:

So I see a couple of objections here to the idea that I will try to address.

First is MAL's thinking that this will undo any C code, which it won't. The 
idea is that stdlib modules that do not inherently rely on other C code (e.g. 
sqlite3 does not fall underneath this) would have a pure Python implementation 
with possible C enhancements. In the case of datetime that  code is done, so it 
won't go anywhere. In this case it would be bringing in a pure Python 
implementation like the one PyPy maintains. You can look at heapq if you want 
an existing example of what it looks like to maintain a pure Python and C 
version of a module.

Alexander is worried about performance because of Python shims and duplication 
of work. For the performance issue, there is none. If you look at something 
like heapq you will see that there is an `import *` in there to pull in all 
extension code; there is no Python shim to pass through if you don't engineer 
the extension that way. So in datetime's case all of the extension code would 
just get pulled into datetime.py directly and not have any indirection cost.

As for duplication of work, we already have that with datetime in the other 
Python VMs. IronPython, Jython, and PyPy have to do their own version of 
datetime because the stdlib doesn't provide a pure Python version for them to 
use. So while CPython might not be duplicating work, other people are. Besides, 
people typically prototype in Python anyway (including you, Alexander, for the 
UTC patch) and then write the C code, so there really isn't any wasted 
development cycles by having the Python and C version already.

The key thing to remember is that this is so the VMs other than CPython are not 
treated as second-class. They are legit implementations just like CPython, but 
because we have this legacy stuff written in C in the stdlib they are put at a 
disadvantage. It would be better to pool resources and make sure everyone gets 
to use an equivalent standard library when possible.

And I should also mention I expect the PyPy folks to be the ones to move their 
code over; I would never expect anyone to re-implement datetime from scratch.

--

___
Python tracker 

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

[issue8935] Syntax error in os.py

[Ezio Melotti]

Ezio Melotti  added the comment:

In 2.6 b"" is valid syntax.
If you are using 2.6 modules on Python 2.4 you will probably see several more 
errors.

--
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

___
Python tracker 

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

[issue8936] webbrowser regression on windows

[anatoly techtonik]

New submission from anatoly techtonik :

webbrowser.open("127.0.0.1:8080") opens page in IE even if default system 
browser is Chrome.

--
components: Library (Lib), Windows
messages: 107297
nosy: techtonik
priority: normal
severity: normal
status: open
title: webbrowser regression on windows
versions: Python 2.6, Python 2.7

___
Python tracker 

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

[issue7989] Transition time/datetime C modules to Python

[anatoly techtonik]

anatoly techtonik  added the comment:

It would be nice to see the transition accompanied by some tutorial that could 
be used as an example for other similar tasks.

--
nosy: +techtonik

___
Python tracker 

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

[issue8936] webbrowser regression on windows

[Brian Curtin]

Brian Curtin  added the comment:

See also #8232

--
nosy: +brian.curtin
stage:  -> unit test needed
type:  -> behavior
versions:  -Python 2.6

___
Python tracker 

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

[issue8936] webbrowser regression on windows

[Brian Curtin]

Brian Curtin  added the comment:

Also, since you stated that this is a regression -- what was the last version 
you saw this work in?

--

___
Python tracker 

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

[issue8936] webbrowser regression on windows

[Ezio Melotti]

Ezio Melotti  added the comment:

If you want it to open it with the default browser you have to specify the 
protocol (e.g. webbrowser.open("http://127.0.0.1:8080/";)).
I don't know exactly why webbrowser decides to open 
webbrowser.open("127.0.0.1:8080") with IE, but the behavior seems consistent in 
all the versions, so it's not a regression.

--
nosy: +ezio.melotti, georg.brandl

___
Python tracker 

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

[issue7989] Transition time/datetime C modules to Python

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Brett,

Thanks for your explanation.  It looks like I misunderstood the proposal.  I 
though the idea was to have some methods of e.g. date type implemented in 
python and some in C.  What you propose is much simpler.  Effectively, your 
proposal is "let's distribute a pure python implementation of datetime with 
CPython."  I don't have any problem with this.  Patches welcome!

--

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I am changing the title to match Brett's explanation better.  Note that since 
the time module is a thin wrapper around C library calls, it falls under 
inherently relying on C code exception.

--
title: Transition time/datetime C modules to Python -> Add pure Python 
implementation of datetime module to CPython

___
Python tracker 

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

[issue8937] SimpleHTTPServer should contain usage example

[anatoly techtonik]

New submission from anatoly techtonik :

Currently SimpleHTTPServer docs contains phrase "For example usage, see the 
implementation of the test() function." with no reference where this test() 
function is located. This is not user friendly.

--
assignee: d...@python
components: Documentation
messages: 107304
nosy: d...@python, techtonik
priority: normal
severity: normal
status: open
title: SimpleHTTPServer should contain usage example
versions: Python 2.6, Python 2.7

___
Python tracker 

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

[issue8936] webbrowser regression on windows

[anatoly techtonik]

anatoly techtonik  added the comment:

2.5 threw exception

--

___
Python tracker 

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

[issue8936] webbrowser regression on windows

[anatoly techtonik]

anatoly techtonik  added the comment:

webbrowser.open("%s:%s" % (HOST,PORT))
  File "C:\Python25\lib\webbrowser.py", line 61, in open
if browser.open(url, new, autoraise):
  File "C:\Python25\lib\webbrowser.py", line 518, in open
os.startfile(url)
WindowsError: [Error -2147217406] Windows Error 0x80041002: '127.0.0.1:8080'


I do not mind if new Python would handle this exception correctly, but it 
doesn't launching wrong browser. If I specify "http://"; prefix - the Chrome 
launched as expected. Note that if "127.0.0.1:8080" is executed from shell 
(search menu or run dialog) - IE is not started by Vista.

--

___
Python tracker 

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