[issue4326] type of UserList instance returns class instead of instance

[Georg Brandl]

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

What good is a comparison with InstanceType for? If you want to check
whether it's an instance of a custom class, you'll have to check for
instances of new-style classes anyway. If you want to check for UserList
instances, use isinstance().

--
nosy: +georg.brandl

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4312] Unicode in distutils meta-data?

[Georg Brandl]

Changes by Georg Brandl <[EMAIL PROTECTED]>:


--
assignee: georg.brandl -> loewis
nosy: +loewis

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4324] locale documentation is inconsistent

[Georg Brandl]

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

Thanks, fixed in r67224.

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

[issue4328] "à" in u"foo" raises a misleading error

[Ezio Melotti]

New submission from Ezio Melotti <[EMAIL PROTECTED]>:

With Python 2.x:
>>> 'à' in u'foo'
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: 'in ' requires string as left operand
>>> 'à' in u'xàx'
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: 'in ' requires string as left operand

The error claims that "'in ' requires string as left operand"
when actually the left operand *is* a string.

With Python2.6 with unicode_literals:
>>> print(b'\x85')
à
>>> b'\x85' in 'foo'
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'in ' requires string as left operand

With Python3.x the error is slightly different:
TypeError: 'in ' requires string as left operand, not bytes

but then it works with:
>>> b'f' in 'foo'
True

This problem seems somehow related to the implicit decoding of 'à'. I
guess that 'à' in u'foo' should raise a UnicodeDecodeError ('xxx' codec
can't decode byte 0x85 ...), not a TypeError.

--
components: Unicode
messages: 75907
nosy: ezio.melotti
severity: normal
status: open
title: "à" in u"foo" raises a misleading error
versions: Python 2.4, Python 2.5, Python 2.5.3, 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

[issue2706] datetime: define division timedelta/timedelta

[Mark Dickinson]

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

> timedelta /  should be disallowed in true division mode.

I don't understand this;  why should the division mode affect
division operations involving timedeltas at all?  The meaning
of "/" is unaffected by the division mode for float/float or
float/int;  why should timedeltas be any different?

I vote +1 for timedelta/timedelta and timedelta/float (regardless
of division mode).  timedelta / timedelta is the one obvious way
to find out 'how many A's in B', and the one that it's natural
to try first, before looking for (timedelta -> float) conversion
methods.

--
nosy: +marketdickinson

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2706] datetime: define division timedelta/timedelta

[Mark Dickinson]

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

By the way, I assume that any plan to add this division would also include 
adding the inverse operation:

timedelta * float -> timedelta.

It wouldn't make a whole lot of sense to have one without the other.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4291] Allow Division of datetime.timedelta Objects

[Mark Dickinson]

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

[Christian]
> float(td1) / float(td2) which is far more obvious than td1 / td2

To me, td1/td2 is more obvious that float(td1)/float(td2).

float(td) involves an arbitrary choice, to return time in *seconds* 
(rather than days, or milliseconds, or ...);  I think this violates 
EIBTI.  To me, the obvious and easy-to-read way to get the number
of seconds is to do the division:

seconds_in_td = td1 / timedelta(seconds = 1)

--
nosy: +marketdickinson

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4329] base64 does not properly handle unicode strings

[Michael Becker]

New submission from Michael Becker <[EMAIL PROTECTED]>:

See below. unicode string causes exception. Explicitly converting it to
a regular string addresses the issue. I only noticed this because my
input string changed to unicode after updating python to 2.6 and django
to 1.0.

>>> import base64
>>>
a=u'aHR0cDovL3NvdXJjZWZvcmdlLm5ldC90cmFja2VyMi8_ZnVuYz1kZXRhaWwmYWlkPTIyNTg5MzUmZ3JvdXBfaWQ9MTI2OTQmYXRpZD0xMTI2OTQ='
>>> b=base64.urlsafe_b64decode(a)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.6/base64.py", line 112, in urlsafe_b64decode
return b64decode(s, '-_')
  File "/usr/local/lib/python2.6/base64.py", line 71, in b64decode
s = _translate(s, {altchars[0]: '+', altchars[1]: '/'})
  File "/usr/local/lib/python2.6/base64.py", line 36, in _translate
return s.translate(''.join(translation))
TypeError: character mapping must return integer, None or unicode
>>> b=base64.urlsafe_b64decode(str(a))
>>> b
'http://sourceforge.net/tracker2/?func=detail&aid=2258935&group_id=12694&atid=112694'

--
components: Unicode
messages: 75911
nosy: mbecker
severity: normal
status: open
title: base64 does not properly handle unicode strings
versions: 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

[issue2736] datetime needs and "epoch" method

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

Le Saturday 15 November 2008 04:17:50 Alexander Belopolsky, vous avez écrit :
> it is really unnecessary because it can be
> written as epoch + timedelta(0, seconds, microseconds).

I tried yesterday and it doesn't work!

datetime.datetime(1970, 1, 1, 1, 0)
>>> t1 = epoch + timedelta(seconds=-166000)
>>> t2 = datetime.fromtimestamp(-166000)
>>> t2
datetime.datetime(1917, 5, 26, 1, 53, 20)
>>> t1 - t2
datetime.timedelta(0)
>>> t2 = datetime.fromtimestamp(-167000)
>>> t2
datetime.datetime(1917, 1, 30, 7, 6, 40)
>>> t1 = epoch + timedelta(seconds=-167000)
>>> t1 - t2
datetime.timedelta(0, 3600)

We lost an hour durint the 1st World War :-)

Whereas my implementation using mktime() works:

-167000.0

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2706] datetime: define division timedelta/timedelta

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

Some examples to help the choice (using the last patch).

int
---

2L
>>> print dt2 * 2
3:08:38
>>> print dt1 - dt2 * 2
0:51:22
>>> divmod(dt1, dt2)
(2L, datetime.timedelta(0, 3082))
>>> print timedelta(0, 3082)
0:51:22

In 4 hours, you can watch the movie twice, and then your have 51 minutes left.

Operations used:
 - timedelta // timedelta
 - timedelta * int
 - divmod(timedelta, timedelta)

float
-

0.21258172822053367
>>> "Progress: %.1f%%" % ((dt1 / dt2) * 100.0)
'Progress: 21.3%'
>>> dt2 * 0.75
...
TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float'
>>> print (dt2 * 3) // 4
1:10:44.25

If you are seen this movie since 20 minutes, you're at 21% of the total. If 
you want to jump to 75%, it will be at 1:10:44.

Note: timedelta * float is not implemented yet.

Operations used:
 - timedelta / timedelta
 - timedelta * int and timedelta // int (because timdelta / float is 
   not implemented yet)

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2666] webbrowser.py doesn't properly handle BROWSER env var

[Oleg Broytmann]

Oleg Broytmann <[EMAIL PROTECTED]> added the comment:

Update the patch.

Added file: http://bugs.python.org/file12015/webbrowser.py.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2666] webbrowser.py doesn't properly handle BROWSER env var

[Oleg Broytmann]

Changes by Oleg Broytmann <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file10072/webbrowser.py.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4328] "à" in u"foo" raises a misleading error

[Matthew Barnett]

Matthew Barnett <[EMAIL PROTECTED]> added the comment:

The left operand is a bytestring and the right operand is a unicode
string, so it makes sense that it raises an exception, although it would
be clearer if it said "'in ' requires unicode string as left
operand".

I agree that if it's going to do implicit decoding so that it'll accept
'f' in u'foo' then it should probably raise a UnicodeDecodeError when
that fails.

If it's reporting a /TypeError/ then it should also reject 'f' in u'foo'.

--
nosy: +mrabarnett

___
Python tracker <[EMAIL PROTECTED]>

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

[issue887237] Machine integers

[Thomas Heller]

Thomas Heller <[EMAIL PROTECTED]> added the comment:

I wonder if a patch for ctypes like this (which is not yet complete)
could be used to implement this, or MUST it be implemented in C?

The patch contains a mixin class that implements the numeric methods. 
However, the actual operation takes place in Python; only the operands
are converted into ctypes types first, the operand is applied to the
value, and the result is converted to a ctypes instance again.

One difficulty with the patch is that the original ctypes code contained
a tp_as_number member where only the nb_nonzero slot was actually
implemented; this prevented the mixin class to do it's work (Python
didn't call the special methods.  I wonder if there is a bug somewhere...).

--
keywords: +patch
Added file: http://bugs.python.org/file12016/ctypes-numbermixins.patch

___
Python tracker <[EMAIL PROTECTED]>

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

[issue2706] datetime: define division timedelta/timedelta

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

On Sat, Nov 15, 2008 at 5:08 AM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
>
> Mark Dickinson <[EMAIL PROTECTED]> added the comment:
>
>> timedelta /  should be disallowed in true division mode.
>
> I don't understand this;  why should the division mode affect
> division operations involving timedeltas at all?

Here is how I think about this:  timedeltas are integers in units of
time.  For simplicity, let's assume we always express timedeltas in
microseconds (us), so timedeltas are things like 1us, 2us, etc.  As
with integers,  we can define true division (/) and floor division
(//) so that 3us/2us = 1.5 and 3us//2us = 1.  Note that the result is
dimensionless.  Similarly, you can divide timedeltas by  dimensionless
integers: 3us/2 = 1.5us and 3us//2 = 1us.  However in python you
cannot have a timedelta representing 1.5us, so timedelta(0, 0, 3)/2
should be en error.  In order to have a timedelta/int true division,
we would need to have another type floattimedelta which would be a
floating point number in units of time.

>  The meaning of "/" is unaffected by the division mode for float/float or
> float/int;  why should timedeltas be any different?

Because they are integers.  If we had a floattimedelta type that would
store timestamp as a float, its division would rightfully not be
affected by the division mode.

> I vote +1 for timedelta/timedelta and timedelta/float (regardless
> of division mode).

What do you vote  timedelta/timedelta should produce in floor division
mode: an int or a float? and what should  timedelta/float produce: a
timedelta or a float?

___
Python tracker <[EMAIL PROTECTED]>

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

[issue1726687] Bug found in datetime for Epoch time = -1

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

on Windows (with Visual Studio), mktime() also sets tm_wday only if 
successful.

But negative time_t are still not allowed by the Microsoft CRT, the 
tests fail.
There are workaround to this - for example python could use techniques 
similar to http://robertinventor.com/software/t64/
 
OTOH, the docs of the time module explicitly says that dates before the 
Epoch are not handled. Do you want to change this? in other words: is 
this a bug or a feature request?
http://docs.python.org/library/time.html

--
nosy: +amaury.forgeotdarc

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4291] Allow Division of datetime.timedelta Objects

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

@Christian

Adding a __float__ method to datetime was entertained back in 2003, but 
was rejected.  The same reasons apply to timedelta:

"""
- A C double doesn't have enough precision for roundtrip guarantees.

- Does it really need to be automatic?  I.e., does it really need to
  be __float__()?  I'd be less against this if it was an explicit
  method, e.g. dt.asposixtime().

--Guido van Rossum (home page: http://www.python.org/~guido/)
"""

http://mail.python.org/pipermail/python-dev/2003-January/032166.html

--
nosy: +belopolsky

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4330] wsgiref.validate doesn't accept arguments to readline

[Ian Bicking]

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

The method wsgiref.validate:InputWrapper.readline doesn't take any
arguments.  It should take an optional size argument.  Though this isn't
part of the WSGI specification, the cgi module uses this argument when
parsing the body, and in practice no applications that use
cgi.FieldStorage (which is most applications) are compatible with
wsgiref.validate as a result.  Simply adding a *args that is passed to
the underlying file fixes this.

--
components: Library (Lib)
messages: 75920
nosy: ianb
severity: normal
status: open
title: wsgiref.validate doesn't accept arguments to readline
versions: 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

[issue4330] wsgiref.validate doesn't accept arguments to readline

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
assignee:  -> pje
nosy: +pje

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4330] wsgiref.validate doesn't accept arguments to readline

[Phillip J. Eby]

Phillip J. Eby <[EMAIL PROTECTED]> added the comment:

No, it shouldn't.  The purpose of wsgiref.validate is to validate spec
compliance, and the use of a readline() argument means that the program
doing the invocation is not valid, per the spec.  wsgiref.validate is
correctly reporting the failure of compliance.

--
resolution:  -> invalid

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4330] wsgiref.validate doesn't accept arguments to readline

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


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

[issue4330] wsgiref.validate doesn't accept arguments to readline

[Ian Bicking]

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

This renders wsgiref.validate.validator completely useless, because it
cannot be used with any existing code.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4330] wsgiref.validate doesn't accept arguments to readline

[Phillip J. Eby]

Phillip J. Eby <[EMAIL PROTECTED]> added the comment:

Uh, Ian, do you not remember being the person who *wrote* this code a 
few years ago?  This is the old paste.lint with a little 
renaming.  Of course it can be used with existing code -- code that 
complies with the WSGI spec.

It's the cgi module that changed, not wsgiref.

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4330] wsgiref.validate doesn't accept arguments to readline

[Ian Bicking]

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

Yes, and I've wanted to deprecate paste.lint, but I can't because people
use it over wsgiref.validate because it had this change applied.  Yes,
cgi.FieldStorage changed, but now that it's changed wsgiref needs to be
compatible with it to be viable.

Mostly the WSGI spec has been wrong on this for some time, but we've
never gone through the process of updating it (though it has been
brought up several times on Web-SIG).

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4040] ignored exceptions in generators (regression?)

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Well, I'll just cross my fingers then. :)

--
resolution:  -> wont fix
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

[issue4328] "à" in u"foo" raises a misleading error

[Ezio Melotti]

Ezio Melotti <[EMAIL PROTECTED]> added the comment:

Usually, when you do operations involving unicode and normal strings,
the latter are coerced to unicode using the default encoding. If the
codec is not able to decode the string a UnicodeDecodeError is raised. E.g.:
>>> 'à' + u'foo'
Traceback (most recent call last):
  File "", line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte 0x85 in position 0:
ordinal not in range(128)
The same error is raised with u'%s' % 'à'.

I think that 'à' in u'foo' should behave in the same way (i.e. try to
decode the string and possibly raise a UnicodeDecodeError). This is
probably the most coherent and backward-compatible solution, at least in
Python2.x. In Python2.x normal and unicode strings are often mixed and
having 'f' in u'foo' that raises a TypeError will probably break lot of
code.

In Python3.x it could make sense, the strings are unicode by default and
you are not supposed to mix byte strings and unicode strings so we may
require an explicit decoding.

The behavior should be consistent for all the operations, if we decide
to raise a TypeError with 'in' it should be raised with '+' and '%' (and
possibly others) 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

[issue4309] ctypes documentation

[David W. Lambert]

David W. Lambert <[EMAIL PROTECTED]> added the comment:

Conversely, if the documentation is correct then my ctypes is flawed.

"None, integers, byte strings and unicode strings are the only native 
Python objects that can directly be used as parameters in these function 
calls. None is passed as a C NULL pointer, byte strings and unicode 
strings are passed as pointer to the memory block that contains their 
data (char * or wchar_t *). Python integers are passed as the platforms 
default C int type, their value is masked to fit into the C type."

--
components: +ctypes -Documentation

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4331] Can't use _functools.partial() created function as method

[scott sadler]

New submission from scott sadler <[EMAIL PROTECTED]>:

Calling a function created by _functools.partial as a method raises an
exception:

"TypeError: method_new() takes exactly n non-keyword arguments (0 given)"

Where method_new is the function passed into partial() and n is the
number of arguments it expects.

This does not happen when using a python version of partial().

Strangely, in the circumstance that I originally encountered the bug,
there was one instance that I was doing this and it _DID WORK_. The
function being passed into partial() was the same as in the place where
it was failing. The only significant difference that I could see was
that the input function to partial() was being imported, rather than
being defined in the same namespace as it was used I was unable to
reproduce it in my test case (attatched).

Tested on 2.6 and 2.5.2

--
components: Extension Modules
files: partialbug.py
messages: 75928
nosy: ssadler
severity: normal
status: open
title: Can't use _functools.partial() created function as method
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file12017/partialbug.py

___
Python tracker <[EMAIL PROTECTED]>

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

[issue4090] Documenting set comparisons and operations

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Attaching a proposed doc fix-up for this little can of worms (and for
issue 4087).

--
keywords: +patch
Added file: http://bugs.python.org/file12018/expr.diff

___
Python tracker <[EMAIL PROTECTED]>

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