from:"sebastian"


New submission from Sebastian Spaeth :

imaplib's Time2Internaldate returns invalid (as localized) INTERNALDATE 
strings. Appending a message with such a time string leads to a:
19 BAD Command Argument Error. 11 (for MS Exchange IMAP servers)

it returned "26-led-2011 18:23:44 +0100", however:

http://tools.ietf.org/html/rfc2060.html defines:
date_month  ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
"Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"

so it expects an English date format.

imaplib's Time2Internaldate uses time.strftime() to create the final string 
which uses the current locale, returning things such as:

"26-led-2011 18:23:44 +0100" rather than "26-Jan-2011 18:23:44 +0100".

For the right thing to do, we would need to set 
locale.setlocale(locale.LC_TIME, '') to get English formatting or we would need 
to use some home-grown parser that hardcodes the proper terms.

--
components: Library (Lib)
messages: 127186
nosy: spaetz
priority: normal
severity: normal
status: open
title: imaplib: Time2Internaldate() returns localized strings
type: behavior
versions: Python 2.6

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

[issue11024] imaplib: Time2Internaldate() returns localized strings


Sebastian Spaeth  added the comment:

P.S. To replicate this in ipython:

import locale, imaplib

locale.setlocale(locale.LC_ALL,'de_CH.utf8')
imaplib.Time2Internaldate(220254431)
Out[1]: '"24-Dez-1976 06:47:11 +0100"'

(Note the German 'Dez' rather than 'Dec')

--

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

[issue11024] imaplib: Time2Internaldate() returns localized strings


Sebastian Spaeth  added the comment:

CC'ing lavajoe as he seemed to be busy with some of imaplib's Date stuff the 
last couple of days.

--
nosy: +lavajoe

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

[issue11024] imaplib: Time2Internaldate() returns localized strings


Sebastian Spaeth  added the comment:

I think I found the issue he mentioned, however it was about the functions 
taking the local time (rather than UTC), which is fine.

The problem is that Time2Internaldate is used for every .append() operation 
internally, producing invalid dates which are handed to the IMAP server. So in 
most cases, the IMAP server will silently ignore the time and use the current 
time (as per IMAP RFC) or it will complain and barf out (as the MS Exchange 
server rightly does.

So this is more than just an inconvenience, it outright prevents intenational 
users from APPENDing new messages to a server (or silently bodges the message 
date) as there is no way around using that function...

Sorry if this sounds like whining :-) I don't even have a patch handy...

--

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

[issue11024] imaplib: Time2Internaldate() returns localized strings

2011-01-28 Thread Sebastian Spaeth


Sebastian Spaeth  added the comment:

> Added file: imaplib_Time2Internaldate_locale_fix.patch

The patch looks very good to me and works. I agree that we should be
returning a bytearray but this is should not be part of this issue.

For all that it's worth:
Signed-off-by: Sebastian Spaeth 

--

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

[issue15566] tarfile.TarInfo.frombuf documentation is out of date

2012-08-06 Thread Sebastian Ramacher


New submission from Sebastian Ramacher:

tarfile.TarInfo.frombuf has gained two more parameters: encoding and errors. 
The documentation of frombuf claims that the only parameter is buf, which is 
not true anymore.

--
assignee: docs@python
components: Documentation
messages: 167553
nosy: docs@python, sebastinas
priority: normal
severity: normal
status: open
title: tarfile.TarInfo.frombuf documentation is out of date
versions: Python 3.2, Python 3.3

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

[issue8800] add threading.RWLock

2012-09-29 Thread Sebastian Noack


Sebastian Noack added the comment:

I would love to see a reader/writer lock implementation shipped with Python's 
threading (and multiprocessing) module. But I have some issues with the patch:

1. I would avoid the terms 'read' and 'write' as those terms are referring just 
to one of many use cases. A better and more generic name would be shared and 
exclusive lock.

2. If we add a new synchronization primitive to the threading module we really 
should add it also to the multiprocessing module, for consistency and to keep 
switching between threading and multiprocessing as easy as it is right now.

3. The methods rdlock() and wrlock() might even block if you call them with 
blocking=False. That's because of they acquire the internal lock in a blocking 
fashion before they would return False.

4. As Antoine already pointed out, it is a bad idea to make acquiring the 
exclusive (write) lock, the default behavior. That clearly violates the Zen of 
Python, since explicit is better than implicit.

5. The issue above only raises from the idea that the RWLock should provide the 
same API as the Lock and RLock primitives. So everywhere where a lock primitive 
is expected, you can pass either a Lock, RLock or RWLock. That is actually a 
good idea, but in that case you should explicitly specify, whether to pass the 
shared (read) or the exclusive (write) lock.

Both issues 4. and 5. only raise from the idea that a shared/exclusive lock 
should be implemented as a single class. But having two different lock 
primitives, one for the shared lock and one for the exclusive lock and a 
function returning a pair of those, would be much more flexible, pythonic and 
compatible with existing lock primitives.

def ShrdExclLock()
  class _ShrdLock(object):
def acquire(self, blocking=True):
  ...

def release(self, blocking=True):
  ...

def __enter__(self):
  self.acquire()
  retrun self

def __exit__(self, exc_value, exc_type, tb):
  self.release()

  class _ExclLock(object):
def acquire(self, blocking=True):
  ...

def release(self, blocking=True):
  ...

def __enter__(self):
  self.acquire()
  retrun self

def __exit__(self, exc_value, exc_type, tb):
  self.release()

  return _ShrdLock(), _ExclLock()

# create a shared/exclusive lock
shrd_lock, excl_lock = ShrdExclLock()

--
nosy: +Sebastian.Noack

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

[issue8800] add threading.RWLock

2012-09-29 Thread Sebastian Noack


Sebastian Noack added the comment:

Using a lock as context manager is the same as calling 
lock.acquire(blocking=True) and it will in fact block while waiting for an 
other thread to release the lock. In your code, the internal lock is indeed 
just hold for a very short period of time while acquiring or releasing a shared 
or exclusive lock, but it might add up to a notable amount of time dependent on 
how much concurrent threads are using the same RWLock and how slow/busy your 
computer is.

But what made me reconsider my point are following facts:

1. For example, when you acquire a shared (read) lock in non-blocking mode and 
False is returned, you assume that an other thread is holding an exclusive 
(write) lock. But that isn't necessarily the case, if it also returns False, 
when the internal lock is acquired by an other thread for example in order to 
acquire or release another shared (read) lock.

2. The internal lock must be acquired also in order to release a 
shared/exclusive lock. And the 'release' method (at least if implemented as for 
Lock and RLock) don't have a 'blocking' argument, anyway.

For that reasons, I think it is ok to block while waiting for the internal 
lock, even if the shared/exclusive lock was acquired in non-blocking mode. At 
least it seems to lead to less unexpected side effects, than returning False in 
case the internal lock is acquired.

--

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

[issue8800] add threading.RWLock

2012-09-29 Thread Sebastian Noack


Sebastian Noack added the comment:

I've added a new patch, that implements a shared/exclusive lock as described in 
my comments above, for the threading and multiprocessing module.

--
Added file: 
http://bugs.python.org/file27350/Added-ShrdExclLock-to-threading-and-multiprocessing.patch

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

[issue8800] add threading.RWLock

2012-09-30 Thread Sebastian Noack

Sebastian Noack added the comment:

I was just waiting for a comment pointing out, that my patch comes without
tests. :) Note that we are still discussing the implementation and this patch
is just a proof of concept. And since the way it is implemented and the API it
provides could still change, its quite pointless to write tests, until we at
least agreed on the API.

I have uploaded a new patch. The way it is implemented now, is more like the
Barrier is implemented. The common code is shared in the threading module and
the shared/exclusive lock objects can be pickled now. I have also fixed a bug
related to acquiring locks in non-blocking mode.

However the code still uses c_uint, but ctypes (and
multiprocessing.sharedtypes) is only imported when ShrdExclLock is called. So
it is just a lazy dependency, now. However the reason why I am using ctypes
instead of python integers for threading and a BufferWrapper for
multiprocessing (as the Barrier does) is, because of 2 of the 4 counters need
to be continuously incremented, and c_uint has the nice feature that it can
overflow, in contrast to python integers and integers in arrays. Also that way
the implementation is simpler and it seems that there isn't much difference
under the hood between using BufferWrapper() and RawValue().

A shared/exclusive lock isn't one lock but two locks, which are synchronized,
but must be acquired separately. Similar to a pipe, which isn't one file, but
one file connected to another file that reads whatever you have written into
the first file. So it isn't strange to create two lock objects, as it also
isn't strange that os.pipe() returns two file descriptors.

Also having a separate lock object for the shared and exclusive lock, each
providing the same API (as Lock and RLock), gives you huge flexibility. You can
acquire both locks using the with statement or pass them separately around. So
for example when you have a function, thread or child process, that should only
be able to acquire either the shared or the exclusive lock, you don't have to
pass both locks. That also means that existing code that expects a lock-like
object will be compatible with both the shared and exclusive lock.

--
Added file:
http://bugs.python.org/file27363/Added-ShrdExclLock-to-threading-and-multiprocessing-2.patch

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

[issue8800] add threading.RWLock


Sebastian Noack added the comment:

Yes, you could also look at the shared/exclusive lock as one lock with 
different states. But this approach is neither more common, have a look at 
Java's ReadWriteLock [1] for example, which works just like my patch does, 
except that a factory is returned instead of a tuple. Nor does it provide any 
of the benefits, I have mentioned before (same API as Lock and RLock, better 
compatibility with existing code an with statement, ability to pass the shared 
or exclusive lock separetly around). But maybe we could satisfy anybody, by 
following Richard's and Antoine's suggestion of returning a named tuple. So you 
could use the ShrdExclLock both ways:

# use a single object
lock = ShrdExclLock()

with lock.shared:
  ...

with lock.exclusive:
  ...

# unpack the the object into two variables and pass them separately around
shrd_lock, excl_lock = ShrdExclLock()

Thread(target=reader, args=(shrd_lock,)).start()
Thread(target=writer, args=(excl_lock,)).start)


The majority of us seems to prefer the terms shared and exclusive. However I 
can't deny that the terms read and write are more common, even though there are 
also notable exmples where the terms shared and exclusive are used [2] [3]. But 
let us ignore how other call it for now, and get to the origin of both set of 
terms, in order to figure out which fits best into Python:

shared/exclusive -> abstract description of what it is
read/write   -> best known use case

The reason why I prefer the terms shared and exculsive, is that it is more 
distinct and less likely to get misunderstand. Also naming a generic 
implementation after a specific use case is bad API design and I don't know any 
other case where that was done, in the Python core library.


[1] 
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReadWriteLock.html
[2] http://www.postgresql.org/docs/9.2/static/explicit-locking.html
[3] http://www.unix.com/man-page/freebsd/9/SX/

--

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

[issue8800] add threading.RWLock


Sebastian Noack added the comment:

@richard: I'm sorry, but both of my patches contain changes to 
'Lib/threading.py' and can be applied on top of Python 3.3.0. So can you 
explain what do you mean, by missing the changes to threading.py?

--

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

[issue8800] add threading.RWLock


Sebastian Noack added the comment:

> If you want to argue it this way, I counter that the attributes
> "shared" and "exclusive" apply to the type of "access to the
> protected object" you are talking about, and yet, the name suggest
> that they are attributes of the lock itself.

A lock's sole purpose is to synchronize access to a protected object or 
context. So naming a lock after its type of protection absolutely makes sense. 
Those names are also not supposed to be attributes of the lock, rather two 
locks (a shared and an exclusive lock) should be created, that might be 
returned as a namedtuple for convenience.

> In that sense, "reader lock" and "writer lock", describe attributes
> of the user of the lock, and the verbs "readlock" and "writelock"
> describe the operation being requested.

The user of the lock isn't necessarily a reader or writer. This is just one of 
many possible use cases. For example in a server application a shared/exclusive 
lock might be used to protect a connection to the client. So every time a 
thread wants to use the connection, a shared lock must be acquired and when a 
thread wants to shutdown the connection, the exclusive lock must be acquired, 
in order to ensure that it doesn't interrupt any thread still processing a 
request for that connection. In that case you clearly wouldn't call the users 
reader and writer.


> The patch looks like it was produced using git rather than hg, so
> perhaps Rietveld got confused by this.  In that case it is a bug
> in Rietveld that it produced a partial review instead of producing
> no review.

Yes, I have imported the Python 3.3.0 tree into a local git repository and 
created the patch that way. Since patches generated with git are still 
compatible with the 'patch' program in order to apply them, I hope that isn't a 
problem.


> Although using namedtuple is probably a good idea, I don't think it
> really adds much flexibility.  This example could just as easily be
> written
>
>  selock = ShrdExclLock()
>
>  Thread(target=reader, args=(selock.shared,)).start()
>  Thread(target=writer, args=(selock.exclusive,)).start()

Yes, that is true, but in some cases it is more convenient to be able unpack 
the shared/exclusive lock into two variables, with a one-liner. And defining a 
namedtuple doesn't require any extra code compared to defining a class that 
holds both locks. In fact it needs less code to be implemented.

However the flexibility comes from having two lock objects, doesn't matter how 
they are accessed, instead as suggested by Kristján to have a single lock 
object, which just provides proxies for use with the with statement.


> I also think it is time to drop the "writer preference" model, since
> it just adds complexity with doubtful benefits.  Sebastian's model
> also does that.

I have implemented the simplest possible acquisition order. The lock acquired 
first will be granted first. Without that (or a more advanced policy) in 
applications with concurrent threads/processes that are heavily using the 
shared lock, the exclusive lock can never be acquired, because of there is 
always a shared lock acquired and before it is released the next shared lock 
will be acquired.

--

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

[issue8800] add threading.RWLock


Sebastian Noack added the comment:

I would love to see how other people would implement a shared/exclusive lock 
that can be acquired from different processes. However it really seems that 
nobody did it before. If you know a reference implementation I would be more 
than happy.

There are plenty of implementations for threading only, but they won't work 
with multiprocessing, due to the limitations in the ways you can share data 
between processes.

--

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

[issue8800] add threading.RWLock


Sebastian Noack added the comment:

Thanks, but as I already said there are a lot of implementations for 
shared/exclusive lock that can be acquired from different threads. But we need 
with threading as well as with multiprocessing.

And by the way POSIX is the standard for implementing UNIX-like systems and not 
an industry standard for implementing anything, including high-level languages 
like Python.

--

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

[issue8800] add threading.RWLock

2012-10-02 Thread Sebastian Noack


Sebastian Noack added the comment:

Exactly, with my implemantation "the lock acquired first will be granted 
first". There is no way that either shared nor exclusive locks can starve, and 
therefore it should satisfy all use cases. Since you can only share simple 
datastructures like integers across processes, I also found that this seems to 
be the only policy (except ignoring the acquisition order at all), that can be 
implemented for multiprocessing.

I have also looked at the seqlock algorithm, which seems to be great for use 
cases where the exclusive lock is acquired rather rarely and where your 
"reader" code is in fact read-only and therefore can be repeated. But in any 
other case a seqlock would break your code. However the algorithm is ultra 
simple and can't be implemented as lock-like object anyway. Though you could 
implement it as context manager, but that would hide the fact that the "reader" 
code will be repeated. So if you find yourself that a seqlock is that what you 
need for your specific use case, you can just use the algorithm like below:

lock = multiprocessing.Value(0)
count = multiprocessing.Value(0)

def do_read():
  while True:
if count.value % 2:
  continue
data = ...
if count.value % 2:
  continue
return data

def do_write(data):
  with lock:
count.value += 1
# write data
count.value += 1

I have also experimented with implementing a shared/exclusive lock on top of a 
pipe and UNIX file locks (https://gist.github.com/3818148). However it works 
only on Unix and only with processes (not threads). Also it turned out that 
UNIX file locks don't implement an acquisition order. So exclusive locks can 
starve, which renders it useless for most use cases.

--

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

[issue8800] add threading.RWLock

2012-10-02 Thread Sebastian Noack


Sebastian Noack added the comment:

@Kristján: Uhh, that is a huge amount of code, more than twice as much (don't 
counting tests) as my implementation, to accomplish the same. And it seems that 
there is not much code shared between the threading and multiprocessing 
implementation. And for what? Ah right, to make the API suck as much as the 
Windows API does. Please tell me more about good coding practice. ;)

--

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

[issue12873] 2to3 incorrectly handles multi-line imports from future

2011-09-01 Thread Sebastian Wiesner


Changes by Sebastian Wiesner :


--
nosy: +lunar

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

[issue12873] 2to3 incorrectly handles multi-line imports from future

2011-09-02 Thread Sebastian Wiesner


Sebastian Wiesner  added the comment:

More precisely, the bug is, that 2to3 refactors the "print()" invocation in 
"test1.py" though it shouldn't because a "print_function" future import is 
present at the beginning of "test1.py".  The cross-check with "test2.py" shows 
that this is due to the multi-line future import in "test1.py" because the 
line-break in the import statement is the only difference between both files.

--

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

[issue12844] Support more than 255 arguments

2011-09-08 Thread Sebastian Ramacher


Changes by Sebastian Ramacher :


--
nosy: +sebastinas

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

[issue12998] Memory leak with CTypes Structure

2011-09-17 Thread Sebastian Wiesner


Sebastian Wiesner  added the comment:

Why should it?  After all, you're sort of abusing ctypes by repeatedly creating 
Struture types over and over again.  C structures that you might want to wrap 
with these types are fixed and known at the time of programming, so there is 
never a need to create the same Structure type twice.  Thus the set of 
Structure subclasses created during the live-time of a program is both, fixed 
and small, so there is no need to limit the cache size.

--
nosy: +lunar

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

[issue16525] wave file module does not support 32bit float format

2012-11-21 Thread Sebastian Kraft


New submission from Sebastian Kraft:

The wave module cannot read audio WAV files containing 32bit float values. This 
is a very common file type for professional audio!

There has already been a patch some years ago which works fine but was finally 
not applied. I can confirm that it does not break anything and only adds 
support for a new number format.

http://bugs.python.org/issue1144504

--
components: Extension Modules, IO
messages: 176077
nosy: Sebastian.Kraft
priority: normal
severity: normal
status: open
title: wave file module does not support 32bit float format
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 
3.4, Python 3.5

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

[issue16525] wave file module does not support 32bit float format

2012-11-24 Thread Sebastian Kraft


Sebastian Kraft added the comment:

Write support is no problem, I will add this.

>From reading the spec in the link you provided I think the implementation in 
>general is OK.

Everything apart WAVE_FORMAT_PCM should have an extension size cbSize, that's 
right. But only WAVE_FORMAT_EXTENSIBLE sets cbSize=22.
So for read access it is not mandatory to check the value when 
WAVE_FORMAT_IEEE_FLOAT, but for writing files I would set this to zero.

There are several other wave formats which also use float data, but most 
important is WAVE_FORMAT_IEEE_FLOAT, and that can be suppoted quite easily 
without many changes.

--

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

[issue16525] wave file module does not support 32bit float format

2012-11-24 Thread Sebastian Kraft


Sebastian Kraft added the comment:

I will create a patch together with a testset of example files and also fill 
out the agreement.

BTW: readframes() returns bad data for 24bit PCM if big_endian==True. 
Furthermore IMO it doesn't make sense to return a byte stream in little endian 
order on a big endian system... What do you think? At least the waves doc 
doesn't mention or specify the endianess which will cause trouble.

--

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

[issue16525] wave file module does not support 32bit float format

2012-11-25 Thread Sebastian Kraft


Sebastian Kraft added the comment:

Attached to this mail you find my patch for the implementation of support for 
8, 16, 24, 32 bit signed int PCM and 32, 64 bit float.

24bit on big endian systems is buggy, but this will be reported in another 
ticket.

The modified test checks all number formats apart form 24bit int. If the patch 
is fine and will be accepted I will also update the doc and send a seperate 
patch for this.

--
keywords: +patch
Added file: http://bugs.python.org/file28122/wave_float_issue16525.patch

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

[issue16525] wave file module does not support 32bit float format

2012-12-01 Thread Sebastian Kraft


Sebastian Kraft added the comment:

Contribution agreement is now attached to my account. So the review can start ;)

--

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

[issue16664] [PATCH] Test Glob: files starting with .

2012-12-11 Thread Sebastian Kreft


New submission from Sebastian Kreft:

Please find attached a patch to improve the test cases for the glob module. It 
adds test cases for files starting with '.'.

--
components: Tests
files: python.patch
keywords: patch
messages: 177345
nosy: Sebastian.Kreft
priority: normal
severity: normal
status: open
title: [PATCH] Test Glob: files starting with .
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file28281/python.patch

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

[issue16664] [PATCH] Test Glob: files starting with .

2012-12-13 Thread Sebastian Kreft


Sebastian Kreft added the comment:

The docs don't say anything about it. However the code is there (docs bug 
probably). 

See the following lines in glob.py:
57 if pattern[0] != '.':
58 names = [x for x in names if x[0] != '.']
59 return fnmatch.filter(names, pattern)

The documentation is even harder to follow.

The glob docs say:
"The pattern may contain simple shell-style wildcards a la fnmatch."

but the fnmatch docs say:
"Similarly, filenames starting with a period are not special for this module, 
and are matched by the * and ? patterns."


The posix standard states that "if a filename begins with a period ( '.' ), the 
period shall be explicitly matched"
(http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13_03).

--

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

[issue16845] warnings.simplefilter should validate input

2013-01-02 Thread Sebastian Berg


New submission from Sebastian Berg:

`warnings.simplefilter` does not validate that the category passed in is 
actually a class. This means that an invalid category leads to a `TypeError` 
whenever a warning would otherwise occur due to `issubclass` check failing.

It is a very small thing, but for usability it would be clearer if this was 
checked right away.

--
messages: 178867
nosy: seberg
priority: normal
severity: normal
status: open
title: warnings.simplefilter should validate input
type: enhancement

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

[issue16525] wave file module does not support 32bit float format

2013-01-17 Thread Sebastian Kraft


Sebastian Kraft added the comment:

Any news or feedback regarding my patch?

--

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

[issue7279] decimal.py: == and != comparisons involving NaNs

2013-02-13 Thread Sebastian Berg


Sebastian Berg added the comment:

This is closed, and maybe I am missing something. But from a general point of 
view, why does hashing of NaN not raise an error as it did for decimals, i.e. 
why was this not resolved exactly the other way around? I am mostly just 
wondering about this it is not a problem for me.

Hashing NaNs seems dangerous and surprising because it might work in 
dicts/sets, but normally doesn't. (The only thing for it to work right would be 
if NaN was a singleton, but that is impossible for subclasses, etc.).

The thing is:

In [16]: s = {float('nan'): 1, float('nan'): 2, float('nan'): 3}
In [17]: s
Out[17]: {nan: 1, nan: 2, nan: 3}

In [18]: s[float('nan')]
KeyError: nan

In [19]: n = float('nan')
In [20]: s = {n: 1, n: 2, n: 3}
In [21]: s
Out[21]: {nan: 3}

This is because `n is n`, and PyObject_RichCompareBool assumes that if `a is b` 
then `a == b` which is simply wrong for NaNs and also makes comparisons  of 
iterables including NaNs an impossible business. NaNs have their unavoidable 
weirdness, but at least for dictionaries/sets it would seem more clear to me if 
they raised an error.

--
nosy: +seberg

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

[issue7279] decimal.py: == and != comparisons involving NaNs

2013-02-13 Thread Sebastian Berg


Sebastian Berg added the comment:

Thanks, yes, you are right, should have googled a bit more anyway. Though I did 
not find much on the hashable vs unhashable itself, so if I ever stumble across 
it again, I will write a mail...

--

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

[issue16525] wave file module does not support 32bit float format

2013-02-16 Thread Sebastian Kraft


Changes by Sebastian Kraft :


Removed file: http://bugs.python.org/file28122/wave_float_issue16525.patch

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

[issue16525] wave file module does not support 32bit float format

2013-02-16 Thread Sebastian Kraft


Sebastian Kraft added the comment:

Thanks for the hint Harvey!
I have updated my patch to include your changes, but only applied the second 
hunk for the following reasons:

Wave_read should not assume any wave format, as it is expected to open a file 
during initialization. So actually the only missing thing was the assignment of 
the wave format during the reading of the format chunk.

setparams() in Wave_write already sets the wavformat a few lines later together 
with the other parameters. So no need to set it twice...

Can you please check if the updated patch works for you?

--
Added file: http://bugs.python.org/file29085/patch

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

[issue6243] getkey() can segfault in combination with curses.ungetch()

2009-06-08 Thread Sebastian Ramacher


Changes by Sebastian Ramacher :


--
nosy: +sebastinas

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

[issue6952] deprecated conversion from string constant to char *

2009-09-21 Thread Sebastian Ramacher


Changes by Sebastian Ramacher :


--
nosy: +sebastinas

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

[issue7036] Doc/reference/datamodel: Slots description needs update

2009-10-02 Thread Sebastian Thiel


New submission from Sebastian Thiel :

The section starting with:
"If a class defines a slot also defined in a base class, the instance
variable
  defined by the base class slot is inaccessible rendering the meaning
of the
  program undefined. [...]"

would need to be revisited as it claims that a check for this issue
might be added in future. As far as I can tell, it has been added in
Python 2.4 or earlier as I get a TypeError in that case.

The attached diff is my attempt to fix this issue.

Kind Regards, 
Sebastian

--
assignee: georg.brandl
components: Documentation
files: docfix.diff
keywords: patch
messages: 93447
nosy: Byron, georg.brandl
severity: normal
status: open
title: Doc/reference/datamodel: Slots description needs update
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 
3.1, Python 3.2
Added file: http://bugs.python.org/file15020/docfix.diff

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

[issue7036] Doc/reference/datamodel: Slots description needs update

2009-10-02 Thread Sebastian Thiel


Sebastian Thiel  added the comment:

Additional Information:

"multiple bases have instance lay-out conflict"

This happens only if I add __slots__ to the bases so that there is no
dict. I can reproduce this easily by indirectly deriving a class from
two bases that both define the same slot. 
It only happens if all classes define __slots__ so there is no dict.

class ac( object ):
__slots__ = "a"

class bc( ac ):
__slots__ = "b"

class cc( ac ):
__slots__ = "c"

class cannotbecreated( bc,cc ):
 pass
 # raises an error.

Actually I don't know whether this is intended or if it is related to
the documentation section I pointed at.

--

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

[issue7382] bytes.getnewargs is broken; copy.copy() therefore doesn't work on bytes, and bytes subclasses can't be pickled by default

2009-11-23 Thread Sebastian Hagen


New submission from Sebastian Hagen :

In either python 3.0, bytes instances cannot be copied, and (even
trivial) bytes subclasses cannot be unpickled unless they explicitly
override __getnewargs__() or __reduce_ex__().

Copy problem:
>>> import copy; copy.copy(b'foo')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.1/copy.py", line 96, in copy
return _reconstruct(x, rv, 0)
  File "/usr/lib/python3.1/copy.py", line 280, in _reconstruct
y = callable(*args)
  File "/usr/lib/python3.1/copyreg.py", line 88, in __newobj__
return cls.__new__(cls, *args)
TypeError: string argument without an encoding

Bytes subclass unpickle problem:
>>> class B(bytes):
...  pass
...
>>> import pickle; pickle.loads(pickle.dumps(B(b'foo')))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.1/pickle.py", line 1373, in loads
encoding=encoding, errors=errors).load()
TypeError: string argument without an encoding


AFAICT, the problem is that bytes.__getnewargs__() returns a tuple with
a single argument - a string - and bytes.__new__() refuses to
reconstruct the instance when called with in that manner. That is,
"bytes.__new__(bytes, *b'foo'.__getnewargs__())" fails with a TypeError.

This does not cause a problem for pickling bytes instances (as opposed
to instances of a subclass of bytes), because both the Python and C
versions of pickle shipped with Python 3.[01] have built-in magic
(_Pickler.save_bytes() and save_bytes(), respectively) to deal with
bytes instances, and therefore never call their __getnewargs__().

The pickle case, in particular, is highly irritating; the error message
doesn't indicate which object is causing the problem, and until you
actually try to load the pickle, there's nothing to indicate that
there's anything problematic about pickling an instance of a subclass of
bytes.

--
components: Library (Lib)
files: pickle_bytes_subclass.py
messages: 95632
nosy: sh
severity: normal
status: open
title: bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on 
bytes, and bytes subclasses can't be pickled by default
type: behavior
versions: Python 3.0, Python 3.1
Added file: http://bugs.python.org/file15387/pickle_bytes_subclass.py

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

[issue7560] Various filename-taking posix methods don't like bytes / buffer objects.


New submission from Sebastian Hagen :

Most of the functions in Python's stdlib that take filename parameters
allow for those parameters to be buffer (such as bytes, bytearray,
memoryview) objects. This is useful for various reasons, among them that
on Posix-likes, file- and pathnames ultimately *are* sequences of bytes.
A number of functions in the posix (and thus, os) module break this
convention:
mkfifo()
mknod()
statvfs()
pathconf()

E.g.:
>>> os.statvfs(b'/')
Traceback (most recent call last):
  File "", line 1, in 
TypeError: statvfs() argument 1 must be string, not bytes

I'm attaching a patch that modifies the abovementioned functions to make
them accept buffer-like objects in addition to string objects; I've
never contributed code to the stdlib, so any general problems with that
patch can be ascribed to my ignorance about established practice (or
inability to program, in the case of downright bugs).

I'm a bit off a loss as what to do about posix.system(). IMO, that one
should also take bytes - at least on posix-like OSes - since it
specifies a commandline, and both the name and the arguments in such
lines are, on posix-likes, sequences of bytes.
I'm not sure how to best reconcile that with the MS Windows version of
that function, however; advice would be welcome.

--
components: Library (Lib)
files: posix_fn_bytes_01.patch
keywords: patch
messages: 96792
nosy: sh
severity: normal
status: open
title: Various filename-taking posix methods don't like bytes / buffer objects.
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file15659/posix_fn_bytes_01.patch

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

[issue7560] Various filename-taking posix methods don't like bytes / buffer objects.


Changes by Sebastian Hagen :


--
type:  -> behavior

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

[issue7560] Various filename-taking posix methods don't like bytes / buffer objects.


Changes by Sebastian Hagen :


Removed file: http://bugs.python.org/file15659/posix_fn_bytes_01.patch

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

[issue7560] Various filename-taking posix methods don't like bytes / buffer objects.


Sebastian Hagen  added the comment:

I'm taking that patch back. More testing would have been in order before
posting; sorry for that, will repost once I've got the obvious problems
worked out.

--

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

[issue7560] Various filename-taking posix methods don't like bytes / buffer objects.


Sebastian Hagen  added the comment:

And further testing reveals that all of this has in fact already been
fixed in trunk. I assumed it hadn't been, because the code for at least
some of the relevant functions in Modules/_posixmodule.c is the same as
in 3.1.1; I didn't know that the samentics for the "s" format parameter
to PyArg_ParseTuple() had been modified. Apologies for the noise.

--

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

[issue7560] Various filename-taking posix methods don't like bytes / buffer objects.


Changes by Sebastian Hagen :


--
status: open -> closed
versions:  -Python 3.2

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

[issue7561] Filename-taking functions in posix segfault when called with a bytearray arg.


New submission from Sebastian Hagen :

Various functions in the 'posix' module that take filename arguments
accept bytearray values for those arguments, and mishandle those objects
in a way that leads to segfaults.

Python 3.1 (r31:73572, Jul 23 2009, 23:41:26)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.mkdir(bytearray(b'/'))
Segmentation fault

There's at least two seperate problems with the way posixmodule handles
these objects. The first is that the code isn't set up to handle NULL
retvals from PyByteArray_AS_STRING(), which occur for zero-byte
bytearray objects. This causes a NULL-pointer dereference in
PyUnicode_FSConverter() if you pass a zero-length bytearray.

The second issue is that release_bytes() calls bytearray_releasebuffer()
with NULL for the first argument, which directly leads to a NULL-pointer
dereference.

I'm attaching a patch against SVN 77001 which should fix both of these
issues.

--
components: Library (Lib)
files: posixmodule_fn_bytearray_fix_01.patch
keywords: patch
messages: 96795
nosy: sh
severity: normal
status: open
title: Filename-taking functions in posix segfault when called with a bytearray 
arg.
type: crash
versions: Python 3.1, Python 3.2
Added file: 
http://bugs.python.org/file15660/posixmodule_fn_bytearray_fix_01.patch

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

[issue7561] Filename-taking functions in posix segfault when called with a bytearray arg.


Sebastian Hagen  added the comment:

Not exactly. The last part fixes the second problem, which you get for
non-zero-length bytearrays. But without the first fix, zero-length
bytearrays still lead to a crash:

Python 3.2a0 (py3k:77001M, Dec 22 2009, 18:17:08)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import posix
>>> posix.mkdir(bytearray(0))
Segmentation fault

That's what the rest of the patch fixes.

--

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

[issue7561] Filename-taking functions in posix segfault when called with a bytearray arg.


Sebastian Hagen  added the comment:

You're correct about PyUnicode_FSConverter(), which is why the very
first part of my patch fixes that function. Only fixing that one will
get rid of the segfaults, but also lead to incorrect error reporting for
the zero-length bytearray case; the bytes2str() modification is to get
the right exceptions.

I don't know which precise semantics PyByteArray_AS_STRING() is
*supposed* to have. I assumed it returning NULL was normal for
0-byte-length arrays, and based my patch off of that.

--

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

[issue7561] Filename-taking functions in posix segfault when called with a bytearray arg.


Sebastian Hagen  added the comment:

Correction: "Only fixing that one will
get rid of the segfaults" ... well, for mkdir() on GNU/Linux, anyway.
POSIX.1-2008 doesn't specify what happens if you call mkdir() with a
NULL pointer, so I guess other conforming implementations might in fact
still segfault at that point - it just happens that the one I tested it
on is too nice to do that.

Either way, passing a NULL pointer to those functions is almost
certainly not a good idea.

--

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

[issue7561] Filename-taking functions in posix segfault when called with a bytearray arg.


Sebastian Hagen  added the comment:

I've glanced at some of the other PyByteArray_AS_STRING() (and
PyByteArray_AsStr(), which inherits this behaviour) uses in the stdlib.
By far the heaviest user is bytearrayobject.c; aside from that, there's
by my count only 24 uses in current trunk. I haven't looked at all of
them in detail, but the ones I have looked at all seem to ensure that
the possible NULL retvals don't cause them problems.

Given that, and considering that bytearray itself uses it for all kinds
of operations, I'd be rather reluctant to add any additional overhead to
this macro absent some authoritative statement that the current
behaviour is bad. We'd definitely get better performance by just having
posixmodule.c pay attention to the retval it gets. [Yes, this is
probably premature optimization; but it's not as if fixing posixmodule.c
takes any massive changes either, so I'm not too worried about
additional code complexity in this particular case.]

--

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

[issue7561] Filename-taking functions in posix segfault when called with a bytearray arg.


Sebastian Hagen  added the comment:

Well, it doesn't *need* to accept them ... but it would certainly be
nice to have. If you've already got the filename in a bytearray object
for some reason, being able to pass it through directly saves you both a
copy and the explicit conversion code, which is a double-win.

>From an interface POV, it'd be even better if memoryview was allowed,
too ... is there a specific reason that it's not? If one kind of simple
readable buffers work, I don't see any good reason not to support all
such objects.

--

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

[issue7561] Filename-taking functions in posix segfault when called with a bytearray arg.


Sebastian Hagen  added the comment:

Oh, and *forcing* use of the PEP 383 hack for such interfaces would
really be the Wrong Thing. Byte sequences are the natural (and most
efficient, and least prone to misunderstandings) way to store filenames
on a posix-like. Storing them as unicode-except-not-really is an
acceptable hack for interfaces that need to standardize on strings for
some reasons, but that really doesn't apply to these functions, and I'd
always store such filenames as bytes if I know I'm running on a posix-like.

--

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

[issue3001] RLock's are SLOW

2008-06-21 Thread sebastian serrano


sebastian serrano <[EMAIL PROTECTED]> added the comment:

Running with python -O the timing gets a little closer between Lock and
RLock. This code won't be easy to improve in performance. 
The heaviest call is current_thread(), used at lines:
117:me = current_thread()
137:if self.__owner is not current_thread():

and only consist on:
788: def current_thread():
789: try:
790: return _active[_get_ident()]
791: except KeyError:
792: ##print "current_thread(): no current thread for", _get_ident()
793: return _DummyThread()

Simple profiler dump:
$../python-trunk/python -O rlock.py 
time Lock 0.720541000366
time RLock 4.90231084824
 44 function calls in 0.982 CPU seconds

   Ordered by: internal time, call count

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   100.3040.0000.3900.000 threading.py:116(acquire)
   100.2780.0000.3600.000 threading.py:136(release)
10.2320.2320.9820.982 rlock.py:27(testRLock)
   200.1680.0000.1680.000
threading.py:788(current_thread)
10.0000.0000.0000.000 threading.py:103(__init__)
10.0000.0000.0000.000 threading.py:98(RLock)
10.0000.0000.0000.000 threading.py:76(__init__)
00.000 0.000  profile:0(profiler)

--
nosy: +sserrano

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3001>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4163] textwrap wordsep_re Unicode

2008-10-21 Thread Sebastian Kirsche


New submission from Sebastian Kirsche <[EMAIL PROTECTED]>:

The attached patch makes textwrap work with strings containing dashes 
and Unicode alphabetic characters. In addition, it fixes the test case 
for issue 1149508, which no longer failed after temporarily undoing the 
corresponding change.


Example 1:
print textwrap.fill(u'Die Empfänger-Auswahl', 13)

Output without patch: 
Die Empf
änger-Auswahl

With patch:
Die
Empfänger-
Auswahl


Example 2:
print textwrap.fill(u'aa ää-ää', 7)

Output without patch:
aa
ää-ää

With patch:
aa ää-
ää

--
components: Library (Lib)
files: textwrap-umlauts.patch
keywords: patch
messages: 75037
nosy: skirsche
severity: normal
status: open
title: textwrap wordsep_re Unicode
type: behavior
versions: Python 2.5, Python 2.5.3, Python 2.6, Python 2.7
Added file: http://bugs.python.org/file11848/textwrap-umlauts.patch

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4163>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1699259] replacing char* with const char* in sysmodule.c/.h

2008-11-13 Thread Sebastian Ramacher


Sebastian Ramacher <[EMAIL PROTECTED]> added the comment:

At least a response, finally. 

> * Any reason why PySys_SetPath(char *) is left out?

I guess it I just missed it.
 
> * Same for PySys_SetArgv(int, char **)

That one is non-trivial and requires some rewriting of PySys_SetArgv.
And I didn't have the time to look into it any further.

I attached an updated patch.

Added file: http://bugs.python.org/file11999/sysmodule_const_char_r67215.diff

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1699259>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4411] mro documentation

2008-11-24 Thread Sebastian Wiesner


New submission from Sebastian Wiesner <[EMAIL PROTECTED]>:

The documentation of Python 2.6 and 2.7 only mentions the class
attribute "__mro__" in ABC documentation and in Data model documentation
when explaining description invocation (see search results:
http://docs.python.org/dev/search.html?q=__mro__&check_keywords=yes&area=default)

Imho __mro__ lacks documentation in "Standard Type Hierachy", where
special attributes of fundamental data types are documented.

--
assignee: georg.brandl
components: Documentation
messages: 76355
nosy: georg.brandl, lunar
severity: normal
status: open
title: __mro__ documentation
versions: Python 2.7

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4411>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4577] distutils: -3 warnings (apply)


New submission from Sebastian Rittau <[EMAIL PROTECTED]>:

The attached patch removes all instances of the deprecated "apply"
function from distutils and thereby fixes warnings when run with -3.

--
components: Distutils
files: distutils.diff
keywords: patch
messages: 77233
nosy: srittau
severity: normal
status: open
title: distutils: -3 warnings (apply)
versions: Python 2.6
Added file: http://bugs.python.org/file12263/distutils.diff

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4577>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4577] distutils: -3 warnings (apply)


Sebastian Rittau <[EMAIL PROTECTED]> added the comment:

Oops, missed a closing parenthesis.

Added file: http://bugs.python.org/file12264/distutils.diff

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4577>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4577] distutils: -3 warnings (apply)


Changes by Sebastian Rittau <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file12263/distutils.diff

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4577>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4578] compiler: -3 warnings


New submission from Sebastian Rittau <[EMAIL PROTECTED]>:

The attached patch replaces all instances of "x.has_key(k)" method calls
by "k in x". It also replaces one call to parser.ast2tuple by
parser.st2tuple. This removes deprecation warnings when running in -3 mode.

--
components: Library (Lib)
files: compiler.diff
keywords: patch
messages: 77238
nosy: srittau
severity: normal
status: open
title: compiler: -3 warnings
versions: Python 2.6
Added file: http://bugs.python.org/file12266/compiler.diff

___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4578>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4578] compiler: -3 warnings