[issue3508] range() is not a generator when used in for's

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

The behavior of range is very unlikely to be changed in Python 2.x, for 
backwards compatibility reasons.

But it's a great idea!  So great, in fact, that it's already been 
implemented for Python 3.0.  :-)  There range() behaves like a generator 
(in all contexts);  if you really want a list, you'd write:

list(range(2**20))

Thanks!

--
nosy: +marketdickinson
resolution:  -> rejected
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3508] range() is not a generator when used in for's

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

By the way, do you already know about xrange?

xrange([start,] stop[, step]) -> xrange object

Like range(), but instead of returning a list, returns an object that
generates the numbers in the range on demand.  For looping, this is 
slightly faster than range() and more memory efficient.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2389] Array pickling exposes internal memory representation of elements

[Hrvoje Nikšić]

Hrvoje Nikšić <[EMAIL PROTECTED]> added the comment:

I guess it went unnoticed due to prevalence of little-endian 32-bit
machines.  With 64-bit architectures becoming more and more popular,
this might become a bigger issue.

Raymond, why do you think fixing this bug would complicate porting to
2.6/3.0?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3509] La Lutte, Je Vais Vous Montrer Mon Piquer!

[Jean Brouwers]

New submission from Jean Brouwers <[EMAIL PROTECTED]>:

Soyez heureux avec votre taille et de rendre votre partenaire heureux et 
satisfait.

Alors que VPXL elargissement chirurgie est couteux et parfois dangereux, 
pilules pourrait facilement etre oublie de prendre et d'autres produits sont le 
plus souvent que Travailler pour l'OMS, le VPXL est sur et facile a utiliser.}

Commander VPXL et bienvenue dans le monde de heureux et confiant hommes.

http://surekeep.com

--
files: unnamed
messages: 70775
nosy: MrJean1
severity: normal
status: open
title: La Lutte, Je Vais Vous Montrer Mon Piquer!
Added file: http://bugs.python.org/file11063/unnamed

___
Python tracker <[EMAIL PROTECTED]>

___http://www.w3.org/TR/REC-html40";>








Soyez heureux avec votre taille 
et de rendre votre partenaire heureux et satisfait.
Alors que VPXL elargissement chirurgie est 
couteux et parfois dangereux, pilules pourrait facilement etre oublie de 
prendre et d'autres produits sont le plus souvent que Travailler pour l'OMS, le 
VPXL est sur et facile a utiliser.}
Commander VPXL et bienvenue dans le monde de 
heureux et confiant hommes.
http://surekeep.com";>http://surekeep.com




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

[issue3451] Asymptotically faster divmod and str(long)

[Fredrik Johansson]

Fredrik Johansson <[EMAIL PROTECTED]> added the comment:

Indeed, that seems to be much faster. In the mean time, do you mind if I
steal the code? :-)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3509] La Lutte, Je Vais Vous Montrer Mon Piquer!

[Georg Brandl]

Changes by Georg Brandl <[EMAIL PROTECTED]>:


--
resolution:  -> invalid
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

The documentation and Py3k warning will be ready for the third beta next
week (the remaining part is a lot easier than the initial fix).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3506] Change buffer/memoryview DeprecationWarning

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

The memoryview implementation is still unfinished (in py3k), so I
suggest we drop the warning or comment it out.

--
nosy: +pitrou

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1685] linecache .updatecache fails on utf8 encoded files

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

After a look at the patch and at linecache.py, some comments:
- 'rbU' is strange, the 'U' flag has no effect for binary files, so it
should just be 'rb' instead
- I'm surprised we don't have a test_linecache.py in Lib/test
- The following lines at the end of updatecache() deserve a cleanup:

try:
lines = [line if isinstance(line, str) else str(line, coding)
 for line in lines]
except:
pass  # Hope for the best

- The very shallow "except Exception as msg" should also be restricted
to (IOError, OSError) IMHO.

--
nosy: +pitrou

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2834] re.IGNORECASE not Unicode-ready

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

If nobody (except Amaury :-)) has anything to say about the current
patch, should it be committed?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3492] Zlib compress/decompress functions returning bytearray

[Anand B Pillai]

Anand B Pillai <[EMAIL PROTECTED]> added the comment:

Any updates ? The py3k list is also very silent since the week-end...Thanks!

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3508] range() is not a generator when used in for's

[Diego]

Diego <[EMAIL PROTECTED]> added the comment:

2008/8/6 Mark Dickinson <[EMAIL PROTECTED]>:
>
> Mark Dickinson <[EMAIL PROTECTED]> added the comment:
>
> By the way, do you already know about xrange?
>
> xrange([start,] stop[, step]) -> xrange object
>
> Like range(), but instead of returning a list, returns an object that
> generates the numbers in the range on demand.  For looping, this is
> slightly faster than range() and more memory efficient.
>
> ___
> Python tracker <[EMAIL PROTECTED]>
> 
> ___
>

Traceback (most recent call last):
  File "", line 1, in 
OverflowError: long int too large to convert to int

4294967296L

Traceback (most recent call last):
  File "", line 1, in 
OverflowError: range() result has too many items

Sadly so high numbers are longs and xrange seems to get an integer.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3508] range() is not a generator when used in for's

[Diego]

Diego <[EMAIL PROTECTED]> added the comment:

>>> a = xrange(2**32)
Traceback (most recent call last):
 File "", line 1, in 
OverflowError: long int too large to convert to int

>>> 2**32
4294967296L

>>> a=range(2**32)
Traceback (most recent call last):
 File "", line 1, in 
OverflowError: range() result has too many items



Sadly so high numbers are longs and xrange seems to get an integer.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1985] Bug/Patch: Problem with xml/__init__.py when using freeze.py

[A.M. Kuchling]

Changes by A.M. Kuchling <[EMAIL PROTECTED]>:


--
keywords: +easy

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1432] Strange behavior of urlparse.urljoin

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Senthil: We should ask for advice in the web-sig list to see if this is
enough a "bug to be fixed" now that we're in beta for the releases.

Thanks!

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3510] Site-specific configuration hook documentation incorrect

[P. Roebuck]

New submission from P. Roebuck <[EMAIL PROTECTED]>:

Documentation does not match due to version number inconsistency.

Current:
< Then the following directories are added to sys.path, in this order:
<
<
< /usr/local/lib/python2.3/site-packages/bar
< /usr/local/lib/python2.3/site-packages/foo

Proposed:
> Then the following directories are added to sys.path, in this order:
>
>
> /usr/local/lib/python{X.Y}/site-packages/bar
> /usr/local/lib/python{X.Y}/site-packages/foo

Syntax for proposed documentation fix may be incorrect, but this gives 
the general idea anyway...



--
assignee: georg.brandl
components: Documentation
messages: 70785
nosy: georg.brandl, proebuck
severity: normal
status: open
title: Site-specific configuration hook documentation incorrect
versions: Python 2.4, Python 2.5, Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3508] range() is not a generator when used in for's

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

> Sadly so high numbers are longs and xrange seems to get an integer.

Something like that, yes:  the start, step and length of an xrange object 
are stored internally as C longs (just as Python ints are), and this is 
unlikely to change.

There's been quite a lot of recent discussion about the future of range 
and xrange:  see issue 2690, for example.

Maybe itertools.count would provide part of what you want?  Alternatively, 
if you've got a 64-bit machine you could try using a 64-bit build of 
Python---on platforms where a long is 64 bits, the limits should be 2**63 
instead of 2**31.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2834] re.IGNORECASE not Unicode-ready

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Let's make sure the release manager is OK with this.

--
nosy: +barry

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3300] urllib.quote and unquote - Unicode issues

[Bill Janssen]

Changes by Bill Janssen <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11062/myunquote.py

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3300] urllib.quote and unquote - Unicode issues

[Bill Janssen]

Bill Janssen <[EMAIL PROTECTED]> added the comment:

Here's a patch to parse.py (and test/test_urllib.py) that makes the
various tests (cgi, urllib, httplib) pass.  It basically adds
"unquote_as_string", "unquote_as_bytes", "quote_as_string",
"quote_as_bytes", and then define the existing "quote" and "unquote" in
terms of them.

Added file: http://bugs.python.org/file11064/patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3507] spelling in try.html

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Thanks, this is already fixed in SVN.

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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3505] single/double quote error in Python v2.6b2 documentation

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Thanks, fixed in r65558.

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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3300] urllib.quote and unquote - Unicode issues

[Jim Jewett]

Jim Jewett <[EMAIL PROTECTED]> added the comment:

Is there still disagreement over anything except:

(1)  The type signature of quote and unquote (as opposed to the 
explicit "quote_as_bytes" or "quote_as string").

(2)  The default encoding (latin-1 vs UTF8), and (if UTF-8) what to do 
with invalid byte sequences?

(3)  Would waiting for 3.1 cause too many compatibility problems?

--
nosy: +jimjjewett

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3509] La Lutte, Je Vais Vous Montrer Mon Piquer!

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

When classifying stuff as spam, please also check for attachments that
might have been included in the email message, and show up as files -
files and messages are treated separately in the tracker.

--
nosy: +georg.brandl, loewis -MrJean1

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3300] urllib.quote and unquote - Unicode issues

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Bill, I haven't studied your patch in detail but a few comments:
- it would be nice to have more unit tests, especially for the various
bytes/unicode possibilities, and perhaps also roundtripping (Matt's
patch has a lot of tests)
- quote_as_bytes() should return a bytes object, not a bytearray
- using the "%02X" format looks clearer to me than going through the
_hextable lookup table...
- when the argument is of the wrong type, quote_as_bytes() should raise
a TypeError rather than a ValueError
- why is quote_as_string() hardwired to utf8 while unquote_as_string()
provides a charset parameter? wouldn't it be better for them to be
consistent with each other?

--
nosy: +pitrou

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2065] trunk version does not compile with vs8 and vc6

[Hirokazu Yamamoto]

Changes by Hirokazu Yamamoto <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file11065/ocean-remaining.zip

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3506] Change buffer/memoryview DeprecationWarning

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

How unfinished is it, Antoine? So much that it can't be used, or just to
the extent it doesn't take the same arguments as buffer()? If it is the
latter then the warning should be changed to warn about unsupported
arguments.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2885] Create the urllib package

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

Fixers are in, so this is a done deal.

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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2338] Backport reload() moving to imp.reload()

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

A fixer is not going to work for this since it might require an import
to work. Instead reload() just needs to be added as imp.reload() and the
current warning stays.

--
assignee: collinwinter -> brett.cannon
components: +Extension Modules -2to3 (2.x to 3.0 conversion tool), Interpreter 
Core
priority: critical -> release blocker

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2775] Implement PEP 3108

[Brett Cannon]

Changes by Brett Cannon <[EMAIL PROTECTED]>:


--
dependencies:  -Create the urllib package

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3506] Change buffer/memoryview DeprecationWarning

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

I'm no buffer API/memoryview expert, but at least slicing is not
implemented, and there are almost no unit tests. It can probably be
used, but given the absence of tests and of actual uses in the stdlib,
I'm not sure we can say it is robust and therefore promote it as
replacement.

Hopefully Travis will be able to enlighten us when he is back.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3081] Py_(X)SETREF macros

[Paul Pogonyshev]

Paul Pogonyshev <[EMAIL PROTECTED]> added the comment:

Just to note, I proposed similar macro on the mailing list under the
name Py_ASSIGN.

--
nosy: +_doublep

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3511] Incorrect charset range handling with ignore case flag?

[Matthew Barnett]

New submission from Matthew Barnett <[EMAIL PROTECTED]>:

While working on the regex code in sre_compile.py I came across the
following code in the handling of charset ranges in _optimize_charset:

for i in range(fixup(av[0]), fixup(av[1])+1):
charmap[i] = 1

The function fixup converts the ends of the range to lower case if the
ignore-case flag is present. The problem with this approach is
illustrated below:

>>> import re
>>> print re.match(r'[9-A]', 'A')
<_sre.SRE_Match object at 0x00A78058>
>>> print re.match(r'[9-A]', 'a')
None
>>> print re.match(r'[9-A]', '_')
None
>>> print re.match(r'[9-A]', 'A', re.IGNORECASE)
<_sre.SRE_Match object at 0x00D0BFA8>
>>> print re.match(r'[9-A]', 'a', re.IGNORECASE)
<_sre.SRE_Match object at 0x00A78058>
>>> print re.match(r'[9-A]', '_', re.IGNORECASE)
<_sre.SRE_Match object at 0x00D0BFA8>
>>> 

'_' doesn't lie between '9' and 'A', but it does lie between '9' and 'a'.

Surely the ignore-case flag should not affect whether non-letters are
matched or not?

--
components: Regular Expressions
messages: 70799
nosy: mrabarnett
severity: normal
status: open
title: Incorrect charset range handling with ignore case flag?
type: behavior
versions: Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3511] Incorrect charset range handling with ignore case flag?

[Antoine Pitrou]

Changes by Antoine Pitrou <[EMAIL PROTECTED]>:


--
nosy: +pitrou
priority:  -> normal
versions: +Python 2.6, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3300] urllib.quote and unquote - Unicode issues

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Bill Janssen's "patch" breaks two unittests: test_email and
test_http_cookiejar.  Details for test_email:

==
ERROR: test_rfc2231_bad_character_in_filename
(email.test.test_email.TestRFC2231)
.
.
.
  File "/usr/local/google/home/guido/python/py3k/Lib/urllib/parse.py",
line 267, in unquote_as_string
return str(unquote_as_bytes(s, plus=plus), charset, 'strict')
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe2 in position 13:
unexpected end of data

==
FAIL: test_rfc2231_bad_character_in_charset
(email.test.test_email.TestRFC2231)
--
Traceback (most recent call last):
  File
"/usr/local/google/home/guido/python/py3k/Lib/email/test/test_email.py",
line 3279, in test_rfc2231_bad_character_in_charset
self.assertEqual(msg.get_content_charset(), None)
AssertionError: 'utf-8\\u201d' != None

Details for test_http_cookiejar:

==
FAIL: test_url_encoding (__main__.LWPCookieTests)
--
Traceback (most recent call last):
  File "Lib/test/test_http_cookiejar.py", line 1454, in test_url_encoding
self.assert_("foo=bar" in cookie and version_re.search(cookie))
AssertionError: None

--
nosy: +gvanrossum

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3506] Change buffer/memoryview DeprecationWarning

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

On Wed, Aug 6, 2008 at 12:32 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> I'm no buffer API/memoryview expert, but at least slicing is not
> implemented, and there are almost no unit tests. It can probably be
> used, but given the absence of tests and of actual uses in the stdlib,
> I'm not sure we can say it is robust and therefore promote it as
> replacement.
>

Well, if it can't replace buffer() then the warning needs to change to
just flat-out state that buffer() is gone and not suggest any
replacement.

> Hopefully Travis will be able to enlighten us when he is back.
>

Hopefully.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3506] Change buffer/memoryview DeprecationWarning

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

> Well, if it can't replace buffer() then the warning needs to change to
> just flat-out state that buffer() is gone and not suggest any
> replacement.

+1.  buffer() stinks.  memoryview() rules.  They don't hvae the same use
cases.

Is there truly nobody else who understands PEP 3118 well enough?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3419] multiprocessing module is racy

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

> I believe the conn refused error is another race, the child processes  
> are connecting to a manager which is shutting down/gone

After some research, I think it actually has to do with the value of the 
'backlog' parameter when creating a Listener instance: if there are too 
many queued requests to a socket then further connection requests are 
refused;  the 'backlog' parameter appears to set the maximum size of the 
queue.

...or something like that.  I'm a novice here... :-)

Anyway, in the __init__ method of the Server class, in managers.py, the 
Server creates a Listener instance with the line

self.listener = Listener(address=address, backlog=5)

When I change backlog to 50 instead of 5, I don't see the connection 
refused error any more.

I'm not suggesting that the backlog value should be changed---it 
probably shouldn't.  But this does at least explain why connections can 
be refused, and why they should be retried in that case.

I do still think that the patch, or something like it, should be 
applied.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3300] urllib.quote and unquote - Unicode issues

[Jim Jewett]

Jim Jewett <[EMAIL PROTECTED]> added the comment:

Matt pointed out that the email package assumes Latin-1 rather than UTF-8; I 
assume Bill could patch his patch the same way Matt did, and this would 
resolve the email tests.  (Unless you pronounce to stick with Latin-1)

The cookiejar failure probably has the same root cause; that test is 
encoding (non-ASCII) Latin-1 characters, and urllib.parse.py/Quoter assumes 
Latin-1.

So I see some evidence (probably not enough) for sticking with Latin-1 
instead of UTF-8.  But I don't see any evidence that fixing the semantics 
(encoded results should be bytes) at the same time made the conversion any 
more painful.  

On the other hand, Matt shows that some of those extra str->byte code 
changes might never need to be done at all, except for purity.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3506] Change buffer/memoryview DeprecationWarning

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

On Wed, Aug 6, 2008 at 1:12 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum <[EMAIL PROTECTED]> added the comment:
>
>> Well, if it can't replace buffer() then the warning needs to change to
>> just flat-out state that buffer() is gone and not suggest any
>> replacement.
>
> +1.  buffer() stinks.  memoryview() rules.  They don't hvae the same use
> cases.
>

That settles that then.

> Is there truly nobody else who understands PEP 3118 well enough?

Not me.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3506] Change buffer/memoryview DeprecationWarning

[Brett Cannon]

Changes by Brett Cannon <[EMAIL PROTECTED]>:


--
assignee:  -> brett.cannon

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3300] urllib.quote and unquote - Unicode issues

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Dear GvR,

New code review comments by GvR have been published.
Please go to http://codereview.appspot.com/2827 to read them.

Message:
Hi Matt,

Here's a code review of your patch.

I'm leaning more and more towards wanting this for 3.0, but I have some API
design issues and also some style nits.

I'm cross-linking this with the Python tracker issue, through the subject.

Details:

http://codereview.appspot.com/2827/diff/1/2
File Doc/library/urllib.parse.rst (right):

http://codereview.appspot.com/2827/diff/1/2#newcode198
Line 198: replaced by a placeholder character.
I don't think that's a good default.  I'd rather see it default to strict --
that's what encoding translates to everywhere else.  I believe that lenient
error handling by default can cause subtle security problems too, by hiding
problem characters from validation code.

http://codereview.appspot.com/2827/diff/1/2#newcode215
Line 215: An alias for :func:`quote`, intended for use with a :class:`bytes`
object
I'd rather see this as a wrapper that raises TypeError if the argument  
isn't a
bytes or bytearray instance.  Otherwise it's needless redundancy.

http://codereview.appspot.com/2827/diff/1/2#newcode223
Line 223: Replace ``%xx`` escapes by their single-character equivalent.
Should add what the argument type is -- I vote for str or bytes/bytearray.

http://codereview.appspot.com/2827/diff/1/2#newcode242
Line 242: .. function:: unquote_to_bytes(string)
Again, add what the argument type is.

http://codereview.appspot.com/2827/diff/1/4
File Lib/email/utils.py (right):

http://codereview.appspot.com/2827/diff/1/4#newcode224
Line 224: except:
An unqualified except clause is unacceptable here.  Why do you need this  
anyway?

http://codereview.appspot.com/2827/diff/1/5
File Lib/test/test_http_cookiejar.py (right):

http://codereview.appspot.com/2827/diff/1/5#newcode1450
Line 1450: "%3c%3c%0Anew%C3%A5/%C3%A5",
I'm guessing this test broke otherwise?  Given that this references an RFC,  
is
it correct to just fix it this way?

http://codereview.appspot.com/2827/diff/1/3
File Lib/urllib/parse.py (right):

http://codereview.appspot.com/2827/diff/1/3#newcode10
Line 10: "urlsplit", "urlunsplit"]
Please add all the quote/unquote versions here too.
(They were there in 2.5, but somehow got dropped from 3.0.

http://codereview.appspot.com/2827/diff/1/3#newcode265
Line 265: # Maps lowercase and uppercase variants (but not mixed case).
That sounds like a disaster.  Why would %aa and %AA be correct but not %aA  
and
%Aa?  (Even though the old code had the same problem.)

http://codereview.appspot.com/2827/diff/1/3#newcode283
Line 283: def unquote(s, encoding = "utf-8", errors = "replace"):
Please no spaces around the '=' when used for an argument default (or for a
keyword arg).

Also see my comment about defaulting to 'replace' in the doc file.

Finally -- let's be consistent about quotes.  It seems most of this file  
uses
single quotes, so lets stick to that (except docstrings always use double
quotes).

And more: what should a None value for encoding or errors mean?  IMO it  
should
mean "use the default".

http://codereview.appspot.com/2827/diff/1/3#newcode382
Line 382: safe = safe.encode('ascii', 'ignore')
Using errors='ignore' seems like a mistake -- it will hide errors.

I also wonder why safe should be limited to ASCII though.

http://codereview.appspot.com/2827/diff/1/3#newcode399
Line 399: if ' ' in s:
This test means that it won't work if the input is bytes.  E.g.

urllib.parse.quote_plus(b"abc def")

raises a TypeError.

Sincerely,

   Your friendly code review daemon (http://codereview.appspot.com/).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3300] urllib.quote and unquote - Unicode issues

[Jim Jewett]

Jim Jewett <[EMAIL PROTECTED]> added the comment:

> http://codereview.appspot.com/2827/diff/1/5#newcode1450
> Line 1450: "%3c%3c%0Anew%C3%A5/%C3%A5",
> I'm guessing this test broke otherwise?  

Yes; that is one of the breakages you found in Bill's patch.  (He didn't 
modify the test.)

> Given that this references an RFC,
> is it correct to just fix it this way?

Probably.  Looking at http://www.faqs.org/rfcs/rfc2965.html

(1)  That is not among the exact tests in the RFC.
(2)  The RFC does not specify charset for the cookie in general, but the 
Comment field MUST be in UTF-8, and the only other reference I could find to 
a specific charset was "possibly in a server-selected printable ASCII 
encoding."

Whether we have to use Latin-1 (or document charset) in practice for 
compatibility reasons, I don't know.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2338] Backport reload() moving to imp.reload()

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

Done in r65563.

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

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3419] multiprocessing module is racy

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Here's what's going on with the incref error:

Look in the Server class, in managers.py:  consider a shared object with 
id 'id'.  When a reference to the shared object is created, its id is 
added to the id_to_refcount dictionary:

{id: None}

and *shortly afterwards*, the refcount is incremented to get:

{id: 1}

When the object is deleted or goes out of scope later on, the refcount 
is decref'd, and id is removed entirely from id_to_refcount.

The problem occurs when there are two processes simultaneously asking 
for access to the same object.  If a second process happens to decref 
'id' in between the first process creating the reference and 
incrementing it, then the incref from the first process will fail.  This 
is exactly what's happening (some of the time) in test_remote in the 
test_suite.  The failing sequence of operations is:

initial state: id not in id_to_refcount
(process 1): createid_to_refcount[id] is None
(process 1): increfid_to_refcount[id] == 1
(process 2): createid_to_refcount[id] == 1
(process 1): decrefid not in id_to_refcount
(process 2): increfKeyError!
(process 2): decref(never get here...)

I'm not really familiar enough with the whole multiprocessing module to 
know what the right fix for this is.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3512] Change fsync to use fullfsync on platforms (like OS X) that have/need it

[Ian Charnas]

New submission from Ian Charnas <[EMAIL PROTECTED]>:

fsync on OSX does not actually flush the file to disk as is desired. 
This is a problem because application developers rely on fsync for file
integrity.  SQLite [1] and MySQL [2] and other major database systems
all use 'fullfsync' on OS X instead of fsync, because 'fullfsync'
provides the desired behavior.

Because the documented behavior of python's fsync function is to "force
write of file with filedescriptor to disk", I believe that on OS X the
fullfsync call should be used instead of fsync.

The supplied patch adds this functionality in a non-platform-specific
way.  It checks if there is a FULLFSYNC fcntl call available (using
"#ifdef F_FULLFSYNC", where F_FULLFSYNC is defined in sys/fcntl.h), and
if this symbol is defined then a fnctl(F_FULLFSYNC, fd, 0) is called
instead of fsync.

[1] SQLite uses fullfsync on all platforms that define it:
http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/os_unix.c

[2] MySQL uses fullfsync only on the darwin platform and only when
F_FULLFSYNC is defined as 51, which seems to be short-sighted in that
this symbol may change value in future versions of OS X.  To see this
code, download a mysql 5.x source snapshot and open up
mysql-/innobase/os/os0file.c

--
components: Library (Lib)
files: fullfsync.patch
keywords: patch
messages: 70810
nosy: icharnas
severity: normal
status: open
title: Change fsync to use fullfsync on platforms (like OS X) that have/need it
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file11066/fullfsync.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3512] Change fsync to use fullfsync on platforms (like OS X) that have/need it

[Ian Charnas]

Ian Charnas <[EMAIL PROTECTED]> added the comment:

My patch is against trunk, but really this fix should be applied to all
versions that will have future releases.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1288615] Python code.interact() and UTF-8 locale

[Karen Tracey]

Karen Tracey <[EMAIL PROTECTED]> added the comment:

I just stumbled on this bug, it is still a problem in 2.5 and 2.6.  I
tried the supplied patch on 2.6b2 and it works.  Before the patch:

Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> ustr = u'¿Cómo'  
>>> print ustr
¿Cómo
>>> import code
>>> code.interact()
Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> ustr = u'¿Cómo'  
>>> print ustr
¿Cómo

After the patch:

Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> ustr = u'¿Cómo'
>>> print ustr
¿Cómo
>>> import code
>>> code.interact()
Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> ustr = u'¿Cómo'
>>> print ustr
¿Cómo

I realize it's a pretty little problem, but it was quite puzzling to
track down, because naturally I wasn't doing that exactly but rather
using a tool that under the covers was using code.interact() and mostly
behaves just like a bare python prompt except it was mangling unicode
string literals.  Any chance the fix could get in the code base?  The
last comment makes it sound like the patch was missing at one point. 
It's there now.  Is there any concern about it breaking something?

--
nosy: +kmtracey
versions: +Python 2.4, Python 2.5, Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1288615] Python code.interact() and UTF-8 locale

[Karen Tracey]

Karen Tracey <[EMAIL PROTECTED]> added the comment:

FWIW I also tried the fix on a Windows box with Python 2.5.1.  The
failure there is different since the Windows command prompt apparently
uses cp437 as its encoding:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> ustr = u'¿Cómo'
>>> ustr
u'\xbfC\xf3mo'
>>> print ustr
¿Cómo
>>> import code
>>> code.interact()
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> ustr = u'¿Cómo'
>>> print ustr
Traceback (most recent call last):
  File "", line 1, in 
  File "d:\bin\Python2.5.1\lib\encodings\cp437.py", line 12, in encode
return codecs.charmap_encode(input,errors,encoding_map)
UnicodeEncodeError: 'charmap' codec can't encode character u'\xa8' in
position 0: character maps to 

Applying the patch resulted in correct behavior on Windows as well.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue3513] test_multiprocessing hangs without this patch on win2k

[Hirokazu Yamamoto]

New submission from Hirokazu Yamamoto <[EMAIL PROTECTED]>:

Hello. I'm not familiar with socket, but I found workaround for this
problem. socket.getfqdn("127.0.0.1") returns computer name, but with this
test_multiprocess doesn't work. With 'localhost' test works.

Maybe win2003 community buildbot hangs with same reason?
http://www.python.org/dev/buildbot/community/trunk/x86%20Windows%202003%20trunk/builds/13/step-test/0

--
components: Extension Modules
files: workaround.patch
keywords: patch
messages: 70814
nosy: ocean-city
severity: normal
status: open
title: test_multiprocessing hangs without this patch on win2k
versions: Python 2.6
Added file: http://bugs.python.org/file11067/workaround.patch

___
Python tracker <[EMAIL PROTECTED]>

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