Re: [Python-Dev] casefolding in pathlib (PEP 428)

[Ralf Schmitt]

Guido van Rossum  writes:

> Actually, I've heard of code that dynamically falls back on short
> names when paths using long names exceed the system limit for path
> length (either 256 or 1024 IIRC). But short names pretty much require
> consulting the filesystem, so we can probably ignore them.

The limit is 260 characters. But longer paths can be handled by
prepending \\?\ and using the unicode APIs.

see http://msdn.microsoft.com/en-us/library/aa365247.aspx#maxpath

we have the following code to handle the above insanity:
,
| def prepend_magic_win32(path):
| assert isinstance(path, unicode), "path must be of type unicode"
| 
| if path.startswith(u""):
| if path.startswith(u"?\\"):
| return path
| else:
| return u"?\\UNC\\" + path[2:]
| else:
| return u"?\\" + path
`

-- 
Cheers
Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PYTHON3PATH

[Ralf Schmitt]

"R. David Murray"  writes:

> Please review issue 2375 [1], which is an enhancement request to add a
> PYTHON3PATH environment variable.  Because we have elected to have both
> a python and a python3 command, I think this is an issue worth thinking
> about carefully to make sure we are serving the Python user community
> and easing the transition to python3.  It could be that "use virtualenv"
> is the best answer, but I feel we should think about it carefully to
> make sure that is really true.
>
> [1] http://bugs.python.org/issue2375

The first thing I got while trying to run a python3 prompt few days ago,
was an error. python3 tried to read my $PYTHONSTARTUP file, which used
print statements. people will have to run both python 2 and python 3
code at the same time. Using different environment variables will make
this easier.

- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PYTHON3PATH

[Ralf Schmitt]

Guido van Rossum  writes:

> Somehow the bug site doesn't load for me right now, but I'm -1 on
> this. There are maybe a dozen PYTHON... variables -- we really
> shouldn't try to add PYTHON3 variants for all of them.
>
> Specifically for PYTHONPATH, I feel that its use is always a
> short-time or localized hack, not something you set in your .profile
> nd forget about it (forgetting about it inparticular often leads to
> unnecessary debugging pain later). The better approaches are based on
> site-packages, wrapper scripts, virtualenv, etc.

then at least remove them completely from python3, so one can use them
for his python 2 installation. Otherwise it will stump on some innocent
python 3 program (and cause unnecessary debugging pain).

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PYTHON3PATH

[Ralf Schmitt]

Steven Bethard  writes:

>
> How complicated is your PYTHONSTARTUP file? My suspicion is that you
> could easily write it to work for both Python 2.X and 3.X.

sure. that's exactly what I did. My point is that sharing those
environment variables will cause pain for some people.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PYTHON3PATH

[Ralf Schmitt]

Lennart Regebro  writes:

> On Wed, Jan 13, 2010 at 18:40, Ralf Schmitt  wrote:
>> The first thing I got while trying to run a python3 prompt few days ago,
>> was an error. python3 tried to read my $PYTHONSTARTUP file, which used
>> print statements. people will have to run both python 2 and python 3
>> code at the same time. Using different environment variables will make
>> this easier.
>
> What do you need to do in the PYTHONSTARTUP file?
> Ten years of Python programming, and I didn't even know it existed. :-)

hehe. tab completion:

# -*- mode: python -*- 
# Last changed: 2009-12-23 22:25:15 by ralf

import sys
import os

def initreadline():

try:
import readline
except ImportError:
sys.stdout.write("Module readline not available.\n")
return

import rlcompleter
readline.parse_and_bind("tab: complete")

# Use tab for completions
readline.parse_and_bind('tab: complete')
# This forces readline to automatically print the above list when tab
# completion is set to 'complete'.
readline.parse_and_bind('set show-all-if-ambiguous on')
# Bindings for incremental searches in the history. These searches
# use the string typed so far on the command line and search
# anything in the previous input history containing them.
readline.parse_and_bind('"\C-r": reverse-search-history')
readline.parse_and_bind('"\C-s": forward-search-history')

history = os.path.expanduser("~/.pyhistory") 
if os.path.exists(history):
readline.read_history_file(history)

import atexit
atexit.register(lambda: readline.write_history_file(history))

initreadline()
del initreadline
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PYTHON3PATH

[Ralf Schmitt]

"M.-A. Lemburg"  writes:

>
> Naive users won't have PYTHONPATH or any other Python environment
> variables setup.
>
> Really, if you know that you are going to run Python 3 instead of
> Python 2 or vice-versa it's easy enough to run

You don't even know that you're going to run python. I have 40 python
scripts in my /usr/bin directory. 

>
> . py3env.sh
> or
> . py2env.sh
>
> in order to setup your shell environment, much like you typically
> do when using virtual Python installations or work on different
> projects that require different setups.

No, thanks. I'd rather setup my shell environment in ~/.zshrc, once.

>
> If you just want to separate Python 2 and 3 files, use the
> user site-packages dir which includes the Python version.

Both the bzr and mercurial wiki recommend setting PYTHONPATH in order to
install those programs in a user's home directory. There are still
people running python <2.6.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] versioned .so files for Python 3.2

[Ralf Schmitt]

Barry Warsaw  writes:

>
> Do you have concrete examples?  Without that it's just speculation I can't do
> much to address.  Is the problem big or small?  Easy to work around or not?

Some of the things that need to be adapted are e.g. Makefiles (basically
anything that assumes modules have a certain name), all of the freezers
(cxFreeze, py2exe, ...). The biggest problem probably will be that an
import will load the wrong module or no module at all. I'm just
speculating here...

> "Change is bad" isn't a constructive argument. ;)

Did I make that argument?

>
> That's fine, but it's not the way Debian/Ubuntu works today.  PEP 3149
> adoption will definitely remove significant complication for deploying
> multiple Python versions at the same time on those systems.

You're just moving that complication into python.

- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] versioned .so files for Python 3.2

[Ralf Schmitt]

Matthias Klose  writes:

> Not true. Package managers like dpkg/apt-get, rpm/yum and maybe others
> do this for ages. And yes, the added "complexity" of package managers
> does lead to increased robustness.

but how does sharing things lead to increased robustness (even if it
might be managed by your package manager)? 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] No response to posts

[Ralf Schmitt]

Benjamin Peterson  writes:

> Please, let's stop messing with the tracker for everything. I think
> the current set up works reasonably well, and we should focus on the
> real problem: manpower

Ignoring issues (probably even with some patches attached) will drive
contributors away. That's not the way to increase manpower.

- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3149 thoughts

[Ralf Schmitt]

Barry Warsaw  writes:

>
> Section added:
>
> Windows
> ===
>
> This PEP only addresses build issues on POSIX systems that use the
> ``configure`` script.  While Windows or other platform support is not
> explicitly disallowed under this PEP, platform expertise is needed in
> order to evaluate, describe, and implement support on such platforms.
> It is not currently clear that the facilities in this PEP are even
> useful for Windows.
>

If it's useful on unix like systems, why shouldn't it be useful on
windows? Multiple versions of python can be installed on windows
too. And people might also like to share their packages between
installations.

- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] KeyboardInterrupt not catch

[Ralf Schmitt]

Qi Yong  writes:

> Hello,
>
> With this script, after ctrl-d, ctrl-c exception not catch.
> Is it a python bug or a wrong exception usage? Thanks.
> If with import readline, this problem disappears.

there's already a bug in the issue tracker: http://bugs.python.org/issue1195

Cheers,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] segmentation fault in Python 2.5b3 (trunk:51066)

[Ralf Schmitt]

Hi all,

I've been trying to port our software to python 2.5.
unfortunately I'm getting constantly hit by segfaults.

I've boiled it down to the following code:

[EMAIL PROTECTED]:~/bug$ cat t.py
import array

class Indexer(object):
 maximumForwardSize = property(array.array.fromstring)
[EMAIL PROTECTED]:~/bug$ python t.py
Segmentation fault
[EMAIL PROTECTED]:~/bug$ python
Python 2.5b3 (trunk:51066, Aug  3 2006, 13:18:16)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>>
[18733 refs]
[7182 refs]
[EMAIL PROTECTED]:~/bug$ gdb python
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db 
library "/lib/tls/i686/cmov/libthread_db.so.1".

(gdb) r t.py
Starting program: /home/rs/exp/bin/python t.py
[Thread debugging using libthread_db enabled]
[New Thread -1210304832 (LWP 21660)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210304832 (LWP 21660)]
0x0811b68a in visit_decref (op=0xb7db21d8, data=0x0) at 
Modules/gcmodule.c:270
270 if (PyObject_IS_GC(op)) {
(gdb) bt
#0  0x0811b68a in visit_decref (op=0xb7db21d8, data=0x0) at 
Modules/gcmodule.c:270
#1  0x0814043d in property_traverse (self=0xb7d7b5b4, visit=0x811b654 
, arg=0x0) at Objects/descrobject.c:1235
#2  0x0811b753 in subtract_refs (containers=0x8197d88) at 
Modules/gcmodule.c:295
#3  0x0811c453 in collect (generation=2) at Modules/gcmodule.c:790
#4  0x0811cf76 in PyGC_Collect () at Modules/gcmodule.c:1264
#5  0x0810d5da in Py_Finalize () at Python/pythonrun.c:377
#6  0x08057556 in Py_Main (argc=2, argv=0xbfb5a6f4) at Modules/main.c:516
#7  0x080565ba in main (argc=2, argv=0xbfb5a6f4) at ./Modules/python.c:23
(gdb)

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] segmentation fault in Python 2.5b3 (trunk:51066)

[Ralf Schmitt]

Duncan Booth wrote:
> 
> 
> The moral is to regard the reference counting rules as law: no matter how 
> sure you are that you can cheat, don't or you'll regret it.
> 

Or someone else will regret it, just like in this case. :)

- Ralf

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] unicode hell/mixing str and unicode as dictionary keys

[Ralf Schmitt]

Still trying to port our software. here's another thing I noticed:

d = {}
d[u'm\xe1s'] = 1
d['m\xe1s'] = 1
print d

With python 2.4 I can add those two keys to the dictionary and get:
$ python2.4 t2.py
{u'm\xe1s': 1, 'm\xe1s': 1}

With python 2.5 I get:

$ python2.5 t2.py
Traceback (most recent call last):
   File "t2.py", line 3, in 
 d['m\xe1s'] = 1
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe1 in position 1: 
ordinal not in range(128)

Is this intended behaviour? I guess this might break lots of programs 
and the way python 2.4 works looks right to me.
I think it should be possible to mix str/unicode keys in dicts and let 
non-ascii strings compare not-equal to any unicode string.

At least it should be documented prominently in the "what's new" document.

- Ralf


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] unicode hell/mixing str and unicode as dictionary keys

[Ralf Schmitt]

Ralf Schmitt wrote:
> Still trying to port our software. here's another thing I noticed:
> 
> d = {}
> d[u'm\xe1s'] = 1
> d['m\xe1s'] = 1
> print d
> 
> With python 2.4 I can add those two keys to the dictionary and get:
> $ python2.4 t2.py
> {u'm\xe1s': 1, 'm\xe1s': 1}
> 
> With python 2.5 I get:
> 
> $ python2.5 t2.py
> Traceback (most recent call last):
>File "t2.py", line 3, in 
>  d['m\xe1s'] = 1
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe1 in position 1: 
> ordinal not in range(128)
> 
> Is this intended behaviour? I guess this might break lots of programs 
> and the way python 2.4 works looks right to me.
> I think it should be possible to mix str/unicode keys in dicts and let 
> non-ascii strings compare not-equal to any unicode string.

Also this behaviour makes your programs break randomly, that is, it will 
break when the string you add hashes to the same value that the unicode 
string has (at least that's what I guess..)

- Ralf


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] unicode hell/mixing str and unicode as dictionary keys

[Ralf Schmitt]

M.-A. Lemburg wrote:
> Ralf Schmitt wrote:
>> Ralf Schmitt wrote:
>>> Still trying to port our software. here's another thing I noticed:
>>>
>>> d = {}
>>> d[u'm\xe1s'] = 1
>>> d['m\xe1s'] = 1
>>> print d
>>>
>>> With python 2.4 I can add those two keys to the dictionary and get:
>>> $ python2.4 t2.py
>>> {u'm\xe1s': 1, 'm\xe1s': 1}
>>>
>>> With python 2.5 I get:
>>>
>>> $ python2.5 t2.py
>>> Traceback (most recent call last):
>>>File "t2.py", line 3, in 
>>>  d['m\xe1s'] = 1
>>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe1 in position 1: 
>>> ordinal not in range(128)
>>>
>>> Is this intended behaviour? I guess this might break lots of programs 
>>> and the way python 2.4 works looks right to me.
>>> I think it should be possible to mix str/unicode keys in dicts and let 
>>> non-ascii strings compare not-equal to any unicode string.
>> Also this behaviour makes your programs break randomly, that is, it will 
>> break when the string you add hashes to the same value that the unicode 
>> string has (at least that's what I guess..)
> 
> This is because Unicode and 8-bit string keys only work
> in the same way if and only if they are plain ASCII.

This is okay. But in the case where one is not ASCII I would prefer to 
be able to compare them (not equal) instead of getting a UnicodeError.
I know it's too late to change this, ...

> 
> The reason lies in the hash function used by Unicode: it is
> crafted to make hash(u) == hash(s) for all ASCII s, such
> that s == u.
> 
> For non-ASCII strings, there are no guarantees as to the
> hash value of the strings or whether they match or not.
> 
> This has been like that since Unicode was introduced, so it's
> not new in Python 2.5.
> 

...but in the case of dictionaries this behaviour has changed and in 
prior versions of python dictionaries did work as I expected them to.
Now they don't.

When working with unicode strings and (accidently) mixing with str 
strings, things might seem to work until the first non-ascii string
is given to some code and one gets that UnicodeDecodeError (e.g. when 
comparing them).

If one mixes unicode strings and str strings as keys in a dictionary 
things might seem to work far longer until he tries to put in some non 
ASCII string with the "wrong" hash value and suddenly things go boom.
I'd rather keep the pre 2.5 behaviour.

- Ralf

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] unicode hell/mixing str and unicode as dictionary keys

[Ralf Schmitt]

Jean-Paul Calderone wrote:
> 
> I like the exception that 2.5 raises.  I only wish it raised by default
> when using 'ascii' and u'ascii' as keys in the same dictionary. ;)  Oh,
> and that str and unicode did not hash like they do.  ;)

No problem:

 >>> import sys
 >>> reload(sys)

 >>> sys.setdefaultencoding("base64")
 >>> "a"==u"a"
Traceback (most recent call last):
   File "", line 1, in 
   File "/exp/lib/python2.5/encodings/base64_codec.py", line 42, in 
base64_decode
 output = base64.decodestring(input)
   File "/exp/lib/python2.5/base64.py", line 321, in decodestring
 return binascii.a2b_base64(s)
binascii.Error: Incorrect padding
 >>> "a"=="a"
True
 >>> d={u"a":1, "a":1}
Traceback (most recent call last):
   File "", line 1, in 
   File "/exp/lib/python2.5/encodings/base64_codec.py", line 42, in 
base64_decode
 output = base64.decodestring(input)
   File "/exp/lib/python2.5/base64.py", line 321, in decodestring
 return binascii.a2b_base64(s)
binascii.Error: Incorrect padding

Maybe this is all just a matter of choosing the right defaultencoding ? :)


BTW, python 2.4 also suppresses this exception (when instantiating the 
dictionary)

Does python 2.4 catch any exception when comparing keys (which are not 
basestrings) in dictionaries?


- Ralf

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] unicode hell/mixing str and unicode as dictionary keys

[Ralf Schmitt]

M.-A. Lemburg wrote:
> Ralf Schmitt wrote:
>> Does python 2.4 catch any exception when comparing keys (which are not 
>> basestrings) in dictionaries?
> 
> Yes. It does so for all equality compares that need to be done
> as part of the hash collision algorithm (not only w/r to strings
> and Unicode, but in general).
> 
> This was changed in 2.5, which now reports the exception.
> 

So, this thread isn't about "unicode hell" at all.
I guess this change will break lots of code (or will reveal lots of 
broken code...as it did in my case actually).

- Ralf

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] unicode hell/mixing str and unicode as dictionary keys

[Ralf Schmitt]

Christopher Armstrong wrote:
> On 8/4/06, *Ralf Schmitt* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 
> wrote:
> 
> 
> Maybe this is all just a matter of choosing the right
> defaultencoding ? :)
> 
> 
> 
> Doing this is amazingly stupid. I can't believe how often I hear this 
> suggestion. Apparently the fact that you have to "reload(sys)" to do it 
> isn't warning enough?

Ahh, the twisted people, friendly as I know them. Did you actually 
notice the smiley?

- Ralf


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Dicts are broken Was: unicode hell/mixing str and unicode asdictionarykeys

[Ralf Schmitt]

Martin v. Löwis wrote:
> M.-A. Lemburg schrieb:
>> Hiding programmer errors is not making life easier in the
>> long run, so I'm -1 on having the equality comparison return
>> False.
> 
> There is no error to hide here. The objects are inequal, period.

And in the case of dicts it hides errors randomly...

> 
>> Instead we should generate a warning in Python 2.5 and introduce
>> the exception in Python 2.6.
> 
> A warning about what? That you can't put byte string and Unicode
> strings into the same dictionary (as keys)? Next we start not allowing
> to put numbers and strings into the same dictionary, because there
> is no conversion defined between them?

A warning that an exception has been ignored while adding a key to a 
dict, I guess. I'd see keep those dict changes, this is where real 
programmer errors are hidden.

>> I disagree with this part.
>>
>> Failure to decode a string doesn't imply inequality.
> 
> If the failure is "these bytes don't have a meaningful character
> interpretation", then the bytes are *clearly* not equal to
> some character string.

One could also think of a "magic encoding", which decodes non-ascii 
strings to None, making them compare unequal to any unicode string.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] free(): invalid pointer

[Ralf Schmitt]

Hi all,

I've got another error porting our apps. It's a django app
and stops with (when pressing CTRL-C):

*** glibc detected *** free(): invalid pointer: 0xb684c650 ***



with MALLOC_CHECK=1 and gdb I get the following backtrace:

Program received signal SIGINT, Interrupt.
[Switching to Thread -1209690432 (LWP 10036)]
0xe410 in __kernel_vsyscall ()
(gdb) *** glibc detected *** free(): invalid pointer: 0xb66a22a8 ***

(gdb) bt
#0  0xe410 in __kernel_vsyscall ()
#1  0xb7fbd463 in __waitpid_nocancel () from 
/lib/tls/i686/cmov/libpthread.so.0
#2  0x080ed524 in posix_waitpid (self=0x0, args=0xfe00)
 at ./Modules/posixmodule.c:5502
#3  0x080bec34 in PyEval_EvalFrameEx (f=0x825a3b4, throwflag=0)
 at Python/ceval.c:3565
#4  0x080be459 in PyEval_EvalFrameEx (f=0x81bd60c, throwflag=0)
 at Python/ceval.c:3650
#5  0x080be459 in PyEval_EvalFrameEx (f=0x82354f4, throwflag=0)
 at Python/ceval.c:3650
#6  0x080be459 in PyEval_EvalFrameEx (f=0x81dbb94, throwflag=0)
 at Python/ceval.c:3650
#7  0x080bff75 in PyEval_EvalCodeEx (co=0xb7c91c38, globals=0xb7a3713c,
 locals=0x0, args=0x822fcd0, argcount=1, kws=0x822fcd4, kwcount=0,
 defs=0xb7a33058, defcount=2, closure=0x0) at Python/ceval.c:2832
#8  0x080bd771 in PyEval_EvalFrameEx (f=0x822fb6c, throwflag=0)
 at Python/ceval.c:3661
#9  0x080bff75 in PyEval_EvalCodeEx (co=0xb7dfeba8, globals=0xb7dfd714,
 locals=0x0, args=0x820165c, argcount=2, kws=0x8201664, kwcount=0,
 defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2832
#10 0x080bd771 in PyEval_EvalFrameEx (f=0x82014cc, throwflag=0)
 at Python/ceval.c:3661
#11 0x080bff75 in PyEval_EvalCodeEx (co=0xb7dfede8, globals=0xb7dfd714,
 locals=0x0, args=0x81ec784, argcount=1, kws=0x81ec788, kwcount=0,
 defs=0xb7cfcdb8, defcount=1, closure=0x0) at Python/ceval.c:2832
#12 0x080bd771 in PyEval_EvalFrameEx (f=0x81ec634, throwflag=0)
 at Python/ceval.c:3661
#13 0x080be459 in PyEval_EvalFrameEx (f=0x81ae054, throwflag=0)
 at Python/ceval.c:3650
#14 0x080bff75 in PyEval_EvalCodeEx (co=0xb7de2770, globals=0xb7e319bc,
 locals=0xb7e319bc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
 defcount=0, closure=0x0) at Python/ceval.c:2832
---Type  to continue, or q  to quit---
#15 0x080c00f6 in PyEval_EvalCode (co=0xfe00, globals=0xfe00,
 locals=0xfe00) at Python/ceval.c:494
#16 0x080de682 in PyRun_FileExFlags (fp=0x815f008,
 filename=0xbfdf18b1 "manage.py", start=-512, globals=0xfe00,
 locals=0xfe00, closeit=1, flags=0xbfdefbb8) at 
Python/pythonrun.c:1255
#17 0x080de9f3 in PyRun_SimpleFileExFlags (fp=,
 filename=0xbfdf18b1 "manage.py", closeit=1, flags=0xbfdefbb8)
 at Python/pythonrun.c:861
#18 0x08056a69 in Py_Main (argc=2, argv=0xbfdefc54) at Modules/main.c:496
#19 0xb7e6fea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#20 0x08055fa1 in _start () at ../sysdeps/i386/elf/start.S:119


I'm using Python 2.5b3 (trunk:51066M, Aug  3 2006, 16:55:04).

Sorry for not using the bugtracker (sf sucks). Did you guys already 
settle on a new one?

- Ralf

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] free(): invalid pointer

[Ralf Schmitt]

Ralf Schmitt wrote:
> 
> 
> Sorry for not using the bugtracker (sf sucks). Did you guys already 
> settle on a new one?
> 

And sorry for bothering this list. It seems like this problem is related 
to the python cdb module.

- Ralf

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] SimpleXMLWriter missing from elementtree

[Ralf Schmitt]

Hi,

any chance to get SimpleXMLWriter (and other modules maybe??) getting 
included into xml.etree? Otherwise people might have to stick to the 
original elementtree, which doesn't really make sense, since most of 
elementtree already is included.

- Ralf

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Dict suppressing exceptions

[Ralf Schmitt]

Guido van Rossum wrote:
> 
> - the exception could be narrowed even further by only suppressing the
> exception when startkey and key are both either str or unicode
> instances.
> 

I always assumed dictionaries would work exactly like this. So, at least 
it would now work as I had always expected (and others possibly too).

- Ralf

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] inspect.py very slow under 2.5

[Ralf Schmitt]

Fernando Perez wrote:
> 
> These enormous numbers of calls are the origin of the slowdown, and the more
> modules have been imported, the worse it gets.


--- /exp/lib/python2.5/inspect.py   2006-08-28 11:53:36.0 +0200
+++ inspect.py  2006-09-06 12:10:45.0 +0200
@@ -444,7 +444,8 @@
  in the file and the line number indexes a line in that list.  An 
IOError
  is raised if the source code cannot be retrieved."""
  file = getsourcefile(object) or getfile(object)
-module = getmodule(object)
+#module = getmodule(object)
+module = None
  if module:
  lines = linecache.getlines(file, module.__dict__)
  else:

The problem seems to originate from the module=getmodule(object) in 
findsource. If I outcomment that code (or rather do a module=None),
things seem to be back as normal. (linecache.getlines has been called 
with a None module in python 2.4's inspect.py).

- Ralf

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] inspect.py very slow under 2.5

[Ralf Schmitt]

Nick Coghlan wrote:
> 
> It looks like the problem is the call to getabspath() in getmodule(). This 
> happens every time, even if the file name is already in the modulesbyfile 
> cache. This calls os.path.abspath() and os.path.normpath() every time that 
> inspect.findsource() is called.
> 
> That can be fixed by having findsource() pass the filename argument to 
> getmodule(), and adding a check of the modulesbyfile cache *before* the call 
> to getabspath().
> 
> Can you try this patch and see if you get 2.4 level performance back on 
> Fernando's test?:

no. this doesn't work. getmodule always iterates over 
sys.modules.values() and only returns None afterwards.
One would have to cache the bad file value, or only inspect new/changed 
modules from sys.modules.

> 
> http://www.python.org/sf/1553314
> 
> (Assigned to Neal in the hopes of making 2.5rc2)
> 
> Cheers,
> Nick.
> 

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] inspect.py very slow under 2.5

[Ralf Schmitt]

Nick Coghlan wrote:
> Ralf Schmitt wrote:
>> Nick Coghlan wrote:
>>> It looks like the problem is the call to getabspath() in getmodule(). 
>>> This happens every time, even if the file name is already in the 
>>> modulesbyfile cache. This calls os.path.abspath() and 
>>> os.path.normpath() every time that inspect.findsource() is called.
>>>
>>> That can be fixed by having findsource() pass the filename argument to 
>>> getmodule(), and adding a check of the modulesbyfile cache *before* 
>>> the call to getabspath().
>>>
>>> Can you try this patch and see if you get 2.4 level performance back 
>>> on Fernando's test?:
>> no. this doesn't work. getmodule always iterates over 
>> sys.modules.values() and only returns None afterwards.
>> One would have to cache the bad file value, or only inspect new/changed 
>> modules from sys.modules.
> 
> Good point. I modified the patch so it does the latter (it only calls 
> getabspath() again for a module if the value of module.__file__ changes).

with _filesbymodname[modname] = file changed to 
_filesbymodname[modname] = f
it seems to work ok.

diff -r d41ffd2faa28 inspect.py
--- a/inspect.pyWed Sep 06 13:01:12 2006 +0200
+++ b/inspect.pyWed Sep 06 16:52:39 2006 +0200
@@ -403,6 +403,7 @@ def getabsfile(object, _filename=None):
  return os.path.normcase(os.path.abspath(_filename))

  modulesbyfile = {}
+_filesbymodname = {}

  def getmodule(object, _filename=None):
  """Return the module an object was defined in, or None if not 
found."""
@@ -410,17 +411,23 @@ def getmodule(object, _filename=None):
  return object
  if hasattr(object, '__module__'):
  return sys.modules.get(object.__module__)
+if _filename is not None and _filename in modulesbyfile:
+return sys.modules.get(modulesbyfile[_filename])
  try:
  file = getabsfile(object, _filename)
  except TypeError:
  return None
  if file in modulesbyfile:
  return sys.modules.get(modulesbyfile[file])
-for module in sys.modules.values():
+for modname, module in sys.modules.iteritems():
  if ismodule(module) and hasattr(module, '__file__'):
+f = module.__file__
+if f == _filesbymodname.get(modname, None):
+continue
+_filesbymodname[modname] = f
  f = getabsfile(module)
  modulesbyfile[f] = modulesbyfile[
-os.path.realpath(f)] = module.__name__
+os.path.realpath(f)] = modname
  if file in modulesbyfile:
  return sys.modules.get(modulesbyfile[file])
  main = sys.modules['__main__']
@@ -444,7 +451,7 @@ def findsource(object):
  in the file and the line number indexes a line in that list.  An 
IOError
  is raised if the source code cannot be retrieved."""
  file = getsourcefile(object) or getfile(object)
-module = getmodule(object)
+module = getmodule(object, file)
  if module:
  lines = linecache.getlines(file, module.__dict__)
  else:

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] version-specific PYTHONPATH env var

[Ralf Schmitt]

On 3/9/07, Anthony Baxter <[EMAIL PROTECTED]> wrote:


What do people think about the idea of a version-specific PYTHONPATH
environment variable? Something like PYTHON25PATH or the like.
Reason I ask is that on our production systems, we have a couple of
versions of Python being used by different systems. Yes, yes, in a
perfect world they'd be all updated at the same time, sure. There's
occasionally issues with the PYTHONPATH being pointed at something
like .../lib/python2.4/site-packages or the like, and then have
issues when python2.3 or some other different version is run. If we
allowed people to optionally specify a more specific version this
problem would go away.



Few weeks ago I actually needed exactly this functionality. I worked around
it with a .pth file installed for
each version of python I'm using with the following contents:

import sys; sys.path.insert(0, os.path.expanduser("~/pylib%s.%s" %
sys.version_info[:2]))
import site, os, sys; site.addsitedir(os.path.expanduser("~/pylib%s.%s" %
sys.version_info[:2]))
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] git mirror [Re: CPython hg transition complete]

[Ralf Schmitt]

Georg Brandl  writes:

> I'm very happy to announce that the core Python repository switch
> to Mercurial is complete and the new repository at
> http://hg.python.org/cpython/ is now officially open for cloning,
> and for commits by those who had commit access to SVN.

I've setup a git mirror of that repository on github:
https://github.com/schmir/python

Cheers,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Differences among Emacsen

[Ralf Schmitt]

Barry Warsaw  writes:

>
> In case you missed it, there are now *three* Python modes.  Tim Peters'
> original and best (in my completely unbiased opinion ) python-mode.el
> which is still being developed, the older but apparently removed from Emacs
> python.el and the 'new' (so I've heard) python.el.

https://github.com/fgallina/python.el is the fourth one..
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [RELEASE] Python 2.7.2 release candidate 1

[Ralf Schmitt]

Benjamin Peterson  writes:

> The 2.7.2 changelog is at:
>
>  http://hg.python.org/cpython/file/439396b06416/Misc/NEWS
>

The news file mentions that issue 1195 ("Problems on Linux with Ctrl-D
and Ctrl-C during raw_input") is fixed. That's not true, see:
http://bugs.python.org/msg135671

Does one need special roundup rights to reopen issues?

Cheers,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [RELEASE] Python 2.7.2 release candidate 1

[Ralf Schmitt]

Victor Stinner  writes:

>> Does one need special roundup rights to reopen issues?
>
> Oh, I forgot that one. Please reopen the issue, I will apply your fix instead 
> of mine.

I would love to do that, but as my above question implies I'm either too
stupid to do that or I'm missing the rights to do it :)

Cheers,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] siginterrupt on linux (issue1089358)

[Ralf Schmitt]

Hi all,

I've added a patch implementing a wrapper for siginterrupt on linux/unix
like platforms and attached it to
http://bugs.python.org/issue1089358 (which mentions a need for
siginterrupt).

Any chance to get this in?

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Check for signals during regular expression matches (issue846388)

[Ralf Schmitt]

Hi all,

Currently the re module does not handle signals. I've been once a victim of
such a case in a real world setup (i.e. the python interpreter seems to hang
at 100% CPU  and is not interuptible with control c)

http://bugs.python.org/issue846388 opened 4 years ago contained a patch for
this issue (which ofcourse didn't apply).
I've updated that patch and added an example regular expression, which
'hangs' the python interpreter.
I think this issue should be handled.

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] some bugs that need attention

[Ralf Schmitt]

Hi,

I've taken a look at some bugs in the bugtracker. I think these should be
closed:

http://bugs.python.org/issue1720992 is about automatic imports.

http://bugs.python.org/issue1448325
and
http://bugs.python.org/issue1566086

is about the regular expression engine "hanging". These are duplicates of
http://bugs.python.org/issue1662581 and should be closed.

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] why is mmap a builtin module on windows?

[Ralf Schmitt]

Hi all,

I want to use the mmap module from python trunk with python 2.5.
On Linux I can easily replace it, as it is a dynamically loaded module. On
windows
it is a builtin module and I fear that I must compile python on windows (or
resort to some other ugly hack)

What is the reason for mmap being a builtin module?

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] why is mmap a builtin module on windows?

[Ralf Schmitt]

On Jan 23, 2008 9:01 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:

> >
> > What is the reason for mmap being a builtin module?
>
> On Windows lots of modules are linked into the python main dll. The file
> PC/config.c contains a list of all modules. From the point of the
> maintainer it's much easier to link the modules into the main dll
> instead of creating standalone dlls. I also suspect that it's much
>
faster because relocation is slow (see PC/dllbase_nt.txt). Martin or
> Mark can give you a better answer.
>

ok


>
> Why do you want to overwrite the existing module instead of using a
> different name like ralfmmap?
>
> import ralfmmap as mmap
> sys.modules]'mmap'] = mmap
>

I thought about that (ugly hack) too. I would have to change the imports at
a lot of places (and revert the changes when we switch to python 2.6).
(whereas on Unix I would only have to do install the new mmap module).


- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] why is mmap a builtin module on windows?

[Ralf Schmitt]

On Jan 23, 2008 9:35 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:

>
> It's not an ugly hack, it's a well known feature. Add you don't have to
> change a lot of places, too. It's sufficient to add the alias at the
> entry point of your application (the script that starts your app). Once
> the alias sys.modules]'mmap'] = ralfmmap is set, every import mmap gets
> your ralfmmap.


Well, I have multiple scripts using multiple libraries using the new mmap
objects.
So, I would have to change those scripts (if I don't change the libraries),
or change the libraries. And when I want to distribute my apps with bbfreeze
(similar to py2exe), I also need to handle that  import hackery. This is
what I call ugly :) (at least in comparison to linux).

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] why is mmap a builtin module on windows?

[Ralf Schmitt]

On Jan 23, 2008 10:12 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:

> > On Windows lots of modules are linked into the python main dll. The file
> > PC/config.c contains a list of all modules. From the point of the
> > maintainer it's much easier to link the modules into the main dll
> > instead of creating standalone dlls. I also suspect that it's much
> > faster because relocation is slow (see PC/dllbase_nt.txt). Martin or
> > Mark can give you a better answer.
>
> Actually, that *is* the current answer. That plus a remark
> "Contributions are welcome, as long as they
> a) come with a clear, objective policy on what should go into
> pythonxy.dll and what not, and


I'd say anything that is needed by "import sys, os" is a candidate for being
included.
Currently even the _csv module is a builtin module on windows. But then I
don't know how much slower importing from a .pyd file is..


>
> b) automate all aspects of adding modules that should not go
> into pythonxy.dll according to the policy."
>

i.e. create visual studio project files for those modules? and make them
built automatically?

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] why is mmap a builtin module on windows?

[Ralf Schmitt]

On Jan 26, 2008 12:06 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:

> > b) automate all aspects of adding modules that should not go
> > into pythonxy.dll according to the policy."
> >
> >
> > i.e. create visual studio project files for those modules? and make them
> > built automatically?
>
> And adjust msi.py to package them automatically.
>

I have a working built environment now on windows (turns out it was rather
easy). If time permits, I might have a look at it.

- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python source code on Bazaar vcs

[Ralf Schmitt]

On Thu, Mar 20, 2008 at 8:42 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'm happy to announce that we now have available for public
> consumption, the Python source code for 2.5, 2.6 and 3.0 available
> under the Bazaar distributed version control system.
>

I have also setup a mirror using mercurial: http://hgpy.de/py/
It contains the 2.4, 2.5, trunk and py3k branches (in case anyone wants to
compare this to bzr).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] the release gods are angry at python

[Ralf Schmitt]

On Wed, Mar 26, 2008 at 7:21 AM, Neal Norwitz <[EMAIL PROTECTED]> wrote:

>  * test_xmlrpc transient socket errors
>-
> http://www.python.org/dev/buildbot/stable/g4%20osx.4%20trunk/builds/3101/step-test/0
>
>

These are caused by the accept call returning a nonblocking socket, when the
listening socket itself is nonblocking (which it is). see
http://bugs.python.org/issue1503 for more details.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] test_signal on osx g4

[Ralf Schmitt]

this is http://bugs.python.org/issue1068268

On Tue, Apr 1, 2008 at 5:05 PM, <[EMAIL PROTECTED]> wrote:

> test_signal is failing on osx g4:
>
>test test_signal failed -- Traceback (most recent call last):
>  File
> "/Users/buildslave/bb/trunk.psf-g4/build/Lib/test/test_signal.py", line 151,
> in test_main
>self.fail(tb)
>AssertionError: Traceback (most recent call last):
>  File
> "/Users/buildslave/bb/trunk.psf-g4/build/Lib/test/test_signal.py", line 134,
> in test_main
>self.run_test()
>  File
> "/Users/buildslave/bb/trunk.psf-g4/build/Lib/test/test_signal.py", line 80,
> in run_test
>child = subprocess.Popen(['kill', '-HUP', str(pid)])
>  File "/Users/buildslave/bb/trunk.psf-g4/build/Lib/subprocess.py",
> line 593, in __init__
>errread, errwrite)
>  File "/Users/buildslave/bb/trunk.psf-g4/build/Lib/subprocess.py",
> line 1078, in _execute_child
>data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB
>OSError: [Errno 4] Interrupted system call
>
> This is the code which reads stderr from the child process:
>
>data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB
>os.close(errpipe_read)
>if data != "":
>os.waitpid(self.pid, 0)
>child_exception = pickle.loads(data)
>raise child_exception
>
> I'm not an expert in this stuff my any stretch of the imagination, but
> shouldn't subprocess try harder to read this output?  Something like:
>
>while True:
>try:
>data = os.read(errpipe_read, 1048576) # Exceptions limited to 1
> MB
>except OSError, err:
>if err.errno == errno.EINTR:
>continue
>else:
>raise
>else:
>os.close(errpipe_read)
>if data != "":
>os.waitpid(self.pid, 0)
>child_exception = pickle.loads(data)
>raise child_exception
>break
>
> Maybe not while True, but try a few times at least.
>

> Or is the system supposed to automatically restart interrupted system
> calls?
>

> Skip
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/schmir%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] xmlrpclib and dates before 1900

[Ralf Schmitt]

Hi all,

anyone care to take a look at:
http://bugs.python.org/issue2014
It's about xmlrpclib not being able to send datetime objects with dates
before 1900.
I would like to see this go in and would also like to work on
http://bugs.python.org/issue1745722
(xmlrpc wsgi support).
But this only makes sense if someone also commits it...

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] xmlrpclib and dates before 1900

[Ralf Schmitt]

On Wed, Apr 2, 2008 at 11:42 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:

> Martin v. Löwis schrieb:
> > Can you please explain why this is an important problem?
> > Dates before 1900 have all passed long ago, so they shouldn't
> > occur that often in real applications.
>

In the application where I needed it, the customer wanted to send/store
dates for e.g. the date of birth of some people.


>
> Does xmlrpc support dates for 1900? For historic dates the Julian Day


The xmlrpc spec says dates should be sent in the following format:

 19980717T14:08:55
1900 is a rather arbitrary limit with this format.

Note that the unpatched xmlrpclib is able to receive datetime objects with
dates before 1900:
~/ /usr/bin/python2.5   [EMAIL 
PROTECTED]
Python 2.5.2 (r252:60911, Mar  9 2008, 11:14:55)
[GCC 4.2.3 (Debian 4.2.3-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xmlrpclib, datetime
>>>
xmlrpclib.loads('\n\n18500101T00:00:00\n\n\n',
use_datetime=True)
((datetime.datetime(1850, 1, 1),), None)

Dumping however doesn't work:
>>> xmlrpclib.dumps((datetime.datetime(1850, 1, 1),))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.5/xmlrpclib.py", line 1080, in dumps
data = m.dumps(params)
  File "/usr/lib/python2.5/xmlrpclib.py", line 623, in dumps
dump(v, write)
  File "/usr/lib/python2.5/xmlrpclib.py", line 635, in __dump
f(self, value, write)
  File "/usr/lib/python2.5/xmlrpclib.py", line 725, in dump_datetime
write(value.strftime("%Y%m%dT%H:%M:%S"))
  File "datetime.py", line 791, in strftime
return _wrap_strftime(self, fmt, self.timetuple())
  File "datetime.py", line 181, in _wrap_strftime
"methods require year >= 1900" % year)
ValueError: year=1850 is before 1900; the datetime strftime() methods
require year >= 1900

This ValueError just shows an implementation detail.

Note that it's also possible to send and receive dates before 1900 using
xmlrpclib.DateTime objects.


> Number family (MJD or JDN) or Rata Die are more appropriate and much
> easier to use. I wish somebody could add both to the datetime module.
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] xmlrpclib and dates before 1900

[Ralf Schmitt]

On Thu, Apr 3, 2008 at 5:36 AM, <[EMAIL PROTECTED]> wrote:

>
> It's actually not xmlrpclib which has the limitation, but
> datetime.strftime().  That's a known limitation.  Here's the comment in
> the
> datetime code:
> [snip]
> Personally, I don't think patching xmlrpclib is the right place to "fix"
> this problem.  It's possible that the datetime comment is no longer
> correct
>

yes, you're right. but I didn't feel like writing a strftime implementation
(which has probably even less chance of being committed). This patch is
rather tiny, it's easy to understand and it works now.


> and that limitation should be reconsidered.  I see no other mention of
> PYTHON2K in any .c, .h or .py files in the trunk.
>
> Skip
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] xmlrpclib and dates before 1900

[Ralf Schmitt]

On Thu, Apr 3, 2008 at 5:52 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

>
> I'd like to see this fixed if possible, but I'm not sure how -- the C
> level 'struct tm' has (year - 1900) in the tm_year member, and I'm not
> sure that implementations are required to do anything with negative
> values there. We'd have to reimplement all of strftime ourselves. I'm
> not against that, but there are higher priorities.
>

Have you considered using the pure python datetime implementation from the
pypy project for py3k?
It's even based on your own code :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] __eq__ vs hash

[Ralf Schmitt]

Hi all,

the news file for python 2.6 does not mention that you need to define
__hash__ in case you define __eq__ for a class.
This breaks some code (for me: mercurial and pyparsing).
Shouldn't this be documented somewhere (I also cannot find it in the
whatsnew file).

- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __eq__ vs hash

[Ralf Schmitt]

On Fri, Apr 4, 2008 at 4:38 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

> On Fri, Apr 4, 2008 at 2:46 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
> > the news file for python 2.6 does not mention that you need to define
> > __hash__ in case you define __eq__ for a class.
> > This breaks some code (for me: mercurial and pyparsing).
> > Shouldn't this be documented somewhere (I also cannot find it in the
> > whatsnew file).
>
> Well, technically this has always been the requirement.
>

> What specific code breaks? Maybe we need to turn this into a warning
> in order to be more backwards compatible?
>

I don't feel like digging into mercurial or pyparsing code currently. sorry.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] very bad network performance

[Ralf Schmitt]

Hi all,

I'm using mercurial with the release25-maint branch. I noticed that checking
out a local repository now takes more than
5 minutes (it should be around 30s).

I've tracked it down to this change:
http://hgpy.de/py/release25-maint/rev/e9446c6ab3cd
this is svn revision 61009. Here is the diff inline:

--- a/Lib/socket.py Fri Mar 23 14:27:29 2007 +0100
+++ b/Lib/socket.py Sat Feb 23 20:30:59 2008 +0100
@@ -305,7 +305,7 @@
 self._rbuf = ""
 while True:
 left = size - buf_len
-recv_size = max(self._rbufsize, left)
+recv_size = min(self._rbufsize, left)
 data = self._sock.recv(recv_size)
 if not data:
 break



self._rbufsize if 1, and so the code reads one byte at a time. this is
clearly wrong, I'm posting it to the mailing list, as I don't want
this issue to get lost in the bugtracker.


- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] very bad network performance

[Ralf Schmitt]

On Mon, Apr 14, 2008 at 8:22 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

> Eek! Please use the bug tracker.
>

I 've made some comments on: http://bugs.python.org/issue1092502 (which is
the original issue). However I cannot reopen this issue.

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] very bad network performance

[Ralf Schmitt]

On Mon, Apr 14, 2008 at 8:10 PM, Curt Hagenlocher <[EMAIL PROTECTED]>
wrote:

> On Mon, Apr 14, 2008 at 9:12 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
> >
> > I've tracked it down to this change:
> > http://hgpy.de/py/release25-maint/rev/e9446c6ab3cd
> > this is svn revision 61009.
> > [...]
> > self._rbufsize if 1, and so the code reads one byte at a time
>
> The change is correct, but exposes a flaw earlier in the same method.
> "_rbufsize == 1" represents a request to buffer "by line", which is
> clearly irrelevant in this context.  A request to read n bytes should
> just use the default buffer size if buffering "by line".  Sample patch
> is attached.
>

Sorry to reply on the mailing list. But this change is wrong.
e.g. if you're using a buffer size of 16 bytes and try to read 256 bytes, it
should call recv with a value of 256 and not call recv 16 times with a value
of 16.
However, there should be an upper limit (as shown by the imap bug).

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] very bad network performance

[Ralf Schmitt]

On Mon, Apr 14, 2008 at 11:18 PM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:

>
> On Mon, Apr 14, 2008 at 8:22 PM, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
>
> > Eek! Please use the bug tracker.
> >
>
> I 've made some comments on: http://bugs.python.org/issue1092502 (which is
> the original issue). However I cannot reopen this issue.
>

Curt opened another bug for it:
http://bugs.python.org/issue2632
someone should change the priority.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] very bad network performance

[Ralf Schmitt]

On Tue, Apr 15, 2008 at 12:19 AM, Curt Hagenlocher <[EMAIL PROTECTED]>
wrote:

> On Mon, Apr 14, 2008 at 2:29 PM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
> >
> > Sorry to reply on the mailing list. But this change is wrong.
> > e.g. if you're using a buffer size of 16 bytes and try to read 256
> bytes, it
> > should call recv with a value of 256 and not call recv 16 times with a
> value
> > of 16.
> > However, there should be an upper limit (as shown by the imap bug).
>
> There is an upper limit.  It's called "the buffer size".  If someone
> specifies a buffer size of 16 bytes, it means "read 16 bytes at a
> time".  I don't know why someone would want such a small buffer size,
> but presumably they have their reasons.
>

No, I don't agree. To me buffer size means buffer up to buffer_size bytes in
memory.
It does not mean that it should read only buffer_size bytes at once when
asked to read more bytes than buffer size.

 The upper limit I was talking about is the buffer size limit of the
operating system, i.e. the operating system will at a maximum return N bytes
from recv call. It doesn't make sense to ask for more then, and the original
problem with imaplip asking for 10MB of data and then realloc'ing that
buffer would be gone.


> The only reason "min" is a problem is that there's standard library
> code passing a zero to socket.makefile, which gets turned into a
> bufsize of 1 by the constructor.  I actually agree with Bill Janssen
> -- __init__ is where the real problem lies.  But I think the change to
> read() is safer.
>

again no, if I pass in 4 as buffer size, I don't expect the system to make
1024 calls to recv when I want to read 4096 bytes.

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] very bad network performance

[Ralf Schmitt]

On Tue, Apr 15, 2008 at 1:19 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

>
> But why was imaplib apparently specifying 10MB? Did it know there was
> that much data? Or did it just not want to bother looping over all the
> data in smaller buffer increments (e.g. 64K, which is probably the max
> of what most TCP stacks will give you)?
>

Well, calling read with a size of 10MB should be possible. The problem is
that this value ended up
inside the recv call, which then did the malloc/realloc calls.


>
> If I'm right with my hunch that the TCP stack will probably clamp at
> 64K, perhaps we should use min(system limit, max(requested size,
> buffer size))?
>

yes, this is what I was trying to explain.


>
> --
> --Guido van Rossum (home page: 
> http://www.python.org/~guido/
> )
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] NeedsReview keyword

[Ralf Schmitt]

On Tue, Apr 15, 2008 at 7:21 AM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:

> > I think it would be useful for the tracker to grow a "NeedsReview"
> > keyword. I realize the "patch" keyword does some of this, but it may
> > just represent some initial or trivial work. "NeedsReview" should
> > represent a mature patch that some senior dev needs to look hard at
> > and make the choice.
>
> Not sure what problem that would solve. Over time, I would expect that
> any open patch also grows the "NeedsReview" keyword, making the keyword
> pointless. If somebody specifically should review a certain proposed
> change, the change should be assigned to that person. If someone in
> a group should review, they should be contacted by email.
>

I think it would be nice if that patch keyword could be set by non-admins.
This would mean I didn't have to write to the mailing list asking for people
to look at
some specific bug. Like "did someone look at
http://bugs.python.org/issue2122. This isssue is about mmap.flush not
raising an exception on errors. which I think is a rather severe". (btw. can
someone please look at it? :) )

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] NeedsReview keyword

[Ralf Schmitt]

On Tue, Apr 15, 2008 at 7:54 AM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:

>
> Just name your patch files .patch or .diff the next time, not .txt, and
> the keyword will get automatically set.
>

fine. I used .txt cause I wanted to view it in my browser (without the
browser asking me for an application)


>
>  This isssue is about mmap.flush not
> > raising an exception on errors. which I think is a rather severe". (btw.
> > can someone please look at it? :) )
>
> I've added the patch keyword. I don't think the bug is rather severe,
>

thanks.


> as it only affects the mmap module. I also don't see how this could
> cause data loss if the application works correctly.
>

the flush fails but the programs fails to recognize it? i.e. the program
assumes the data is written to disk but it isn't?

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] NeedsReview keyword

[Ralf Schmitt]

> >
> > the flush fails but the programs fails to recognize it? i.e. the program
> > assumes the data is written to disk but it isn't?
>
> Why would the program fail to recognize it? It should just look at the
> result being returned.
>

sorry no. everything else raises an error. this is not documented (as far as
I can see) and mmap.flush returns 0 on unix if it succeeds, and raises an
exception on unix if it fails.

on windows it returns 1 if it succeeds and 0 if it doesn't (One more time:
on unix it returns 0 if it succeeds).

Regards,
- Ralf


> I agree that this is fairly unpythonic, but I also think that there is
> any data loss that this may cause is the application's fault.
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] mmap.flush [was: NeedsReview keyword]

[Ralf Schmitt]

On Tue, Apr 15, 2008 at 11:20 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:

> > > the flush fails but the programs fails to recognize it? i.e. the
> > program
> > > assumes the data is written to disk but it isn't?
> >
> > Why would the program fail to recognize it? It should just look at
> the
> > result being returned.
> >
> >
> > sorry no.
>
> Sorry no what?
>

mmap.flush returns different values for windows/unix like platforms in case
it succeeds.
mmap.flush raises an exception on unix like platforms for errors.
mmap.flush returns 0 on windows for errors. This is the value which is
returned on unix like platforms for a successful call.
The documentation for mmap.flush does not even mention a return value.

so, still: sorry no, the application should not just look at the result
being returned. The mmap.flush method should be fixed.



> Regards,
> Martin
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mmap.flush [was: NeedsReview keyword]

[Ralf Schmitt]

On Tue, Apr 15, 2008 at 11:49 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:

> > so, still: sorry no, the application should not just look at the result
> > being returned.
>
> If it doesn't want to lose data, it *has* to, because of the way it's
> currently implemented. There is no other way (other than ignoring the
> error) in Python 2.5.x and earlier.
>

My point is it will ignore this error, because the programmer didn't even
know about the return value.
So it will possibly use data. But, it's all in the bug report and I'm only
repeating myself.


>
> > The mmap.flush method should be fixed.
>
> I never debated that. I debated whether that is a "rather severe" issue,
> which I still don't think it is.
>

I didn't recognize that we discussed this phrase. Sorry if I wasted your
time.

Regards,
Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mmap.flush [was: NeedsReview keyword]

[Ralf Schmitt]

On Wed, Apr 16, 2008 at 2:58 PM, Jeroen Ruigrok van der Werven <
[EMAIL PROTECTED]> wrote:

> -On [20080415 23:37], Ralf Schmitt ([EMAIL PROTECTED]) wrote:
> >The documentation for mmap.flush does not even mention a return value.
>
> Fixed in revision 62359.
>

I think documenting this insanity is just insane and doesn't help much.
Anyway, you can now close http://bugs.python.org/issue2122 as wontfix.

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mmap.flush [was: NeedsReview keyword]

[Ralf Schmitt]

On Wed, Apr 16, 2008 at 3:29 PM, Jeroen Ruigrok van der Werven <
[EMAIL PROTECTED]> wrote:

> -On [20080416 15:20], Ralf Schmitt ([EMAIL PROTECTED]) wrote:
> >I think documenting this insanity is just insane and doesn't help much.
> >Anyway, you can now close http://bugs.python.org/issue2122 as wontfix.
>
> Why?
> I added documentation for the current way. I was not aware of the other
> thread's mention of this issue. When your patch goes in --and looking at
> it
> it makes sense to me-- I can easily adjust the documentation to reflect
> the
> new state. :)
>
> I can understand your apparent frustration at not having gotten someone to
> look over your issue, but please: relax. I cannot make source changes,
> only
> documentation.
>

ok. makes sense. sorry, if I offended you.

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] very bad network performance

[Ralf Schmitt]

On Mon, Apr 21, 2008 at 8:10 PM, Gregory P. Smith <[EMAIL PROTECTED]> wrote:

>
>
>
> The 64K hunch is wrong.  The system limit can be found using
> getsockopt(...SO_RCVBUF...).  It can easily be (and often is) set to many
> megabytes either at a system default level or on a per socket level by the
> user using setsockopt.  When the system default is that large, limiting by
> the system limit would not help the 10mb read case.
>

but it would help in the 100mb read case.


>
> Even smaller allocations like 64K cause problems as mentioned in issue
> 1092502 linking to this twisted http://twistedmatrix.com/trac/ticket/1079bug. 
>  twisted's solution was to make the string object returned by a recv as
> short lived as possible by copying it into a StringIO.  We could do the same
> in _fileobject.read() and readline().
>

this approach look reasonable to me.

- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] segfault in 2.5.1

[Ralf Schmitt]

On Fri, Apr 25, 2008 at 3:13 PM, Neal Becker <[EMAIL PROTECTED]> wrote:

> Attempt to write to a mmap which was opened mmap.PROT_READ causes python
> to
> segfault.


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

Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008

[Ralf Schmitt]

On Thu, May 1, 2008 at 10:26 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> This is a reminder that the LAST planned alpha releases of Python 2.6 and
> 3.0 are scheduled for next Wednesday, 07-May-2008.  Please be diligent over
> the next week so that none of your changes break Python.  The stable
> buildbots look moderately okay, let's see what we can do about getting them
> all green:
>
> http://www.python.org/dev/buildbot/stable/
>
> We have a few showstopper bugs, and I will be looking at these more
> carefully starting next week.
>
>
> http://bugs.python.org/[EMAIL 
> PROTECTED],id,activity,versions,status&@sort=activity&@filter=priority,status&@pagesize=50&@startwith=0&priority=1&status=1&@dispname=Showstoppers
>

running the testsuite segfaults on my 64 bit debian testing in test_pyexpat.
This does not happen in a debug build:

test_pyclbr
test_pydoc
test_pyexpat

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2b573851a6e0 (LWP 19486)]
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x2f694f0a in doContent (parser=0x1b4bab0, startTagLevel=0,
enc=0x1b4dba0,
s=0x1b4cb3c "", ' ' ,
"frozenset([frozenset([2]),\n", ' ' , "frozenset([0,\n", '
' ...,
end=0x1b4cb40 ' ' , "frozenset([frozenset([2]),\n", '
' , "frozenset([0,\n", ' ' ...,
nextPtr=0x1b4bae0, haveMore=1 '\001')
at extensions/expat/lib/xmlparse.c:2540
#2  0x2f6972ee in contentProcessor (parser=0x1b4bab0, start=0x0,
end=0x1b4c470 "q\001", endPtr=0x0)
at extensions/expat/lib/xmlparse.c:2003
#3  0x2f698662 in doProlog (parser=0x1b4bab0, enc=0x1b4dba0,
s=0x1b4c738 "", 'a' ...,
end=0x1b4cb40 ' ' , "frozenset([frozenset([2]),\n", '
' , "frozenset([0,\n", ' ' ..., tok=29,
next=0x1b4c738 "", 'a' ..., nextPtr=0x1b4bae0,
haveMore=1 '\001') at extensions/expat/lib/xmlparse.c:3803
#4  0x2f69adc3 in prologInitProcessor (parser=0x1b4bab0,
s=0x1b4c710 "", 'a' ...,
end=0x1b4cb40 ' ' , "frozenset([frozenset([2]),\n", '
' , "frozenset([0,\n", ' ' ...,
nextPtr=0x1b4bae0) at extensions/expat/lib/xmlparse.c:3551
#5  0x2f68cc61 in XML_ParseBuffer (parser=0x1d20670, len=28625724,
isFinal=0) at extensions/expat/lib/xmlparse.c:1562
#6  0x2f689467 in xmlparse_Parse (self=0x1d20670,
args=) at extensions/pyexpat.c:922
#7  0x00419b9d in PyObject_Call (func=0x1a52b48, arg=0x2b7a710,
kw=0x1b4c610) at Objects/abstract.c:2490
#8  0x004902f8 in PyEval_EvalFrameEx (f=0x8cba40,
throwflag=) at Python/ceval.c:3944
#9  0x00494824 in PyEval_EvalCodeEx (co=0x2b5738764558,
globals=, locals=,
args=0x23aa130, argcount=4, kws=0x23aa150, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at Python/ceval.c:2908
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

[Ralf Schmitt]

On Thu, Jun 26, 2008 at 5:33 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

> an explanation about *why* Django cannot even be imported than a
> blanket complaint that this is a disgrace. So why is it?
>


  File "/home/ralf/pediapress/appserver/django/db/models/options.py",
line 198, in _many_to_many
self._fill_m2m_cache()
  File "/home/ralf/pediapress/appserver/django/db/models/options.py",
line 221, in _fill_m2m_cache
cache[field] = None
  File "/home/ralf/pediapress/appserver/django/utils/datastructures.py",
line 75, in __setitem__
super(SortedDict, self).__setitem__(key, value)
TypeError: unhashable type: 'ManyToManyField'


same for sqlalchemy:
egg/sqlalchemy/schema.py", line 113, in __call__
return type.__call__(self, name, metadata, *args, **kwargs)
  File 
"/home/ralf/py26/lib/python2.6/site-packages/SQLAlchemy-0.5.0beta1-py2.6.egg/sqlalchemy/schema.py",
line 207, in __init__
self.primary_key = PrimaryKeyConstraint()
  File 
"/home/ralf/py26/lib/python2.6/site-packages/SQLAlchemy-0.5.0beta1-py2.6.egg/sqlalchemy/schema.py",
line 294, in _set_primary_key
self.constraints.add(pk)
TypeError: unhashable type: 'PrimaryKeyConstraint'


and already discussed:
http://mail.python.org/pipermail/python-dev/2008-April/078421.html

- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

[Ralf Schmitt]

On Thu, Jun 26, 2008 at 6:54 PM,  <[EMAIL PROTECTED]> wrote:
> On 04:42 pm, [EMAIL PROTECTED] wrote:
>>
>> On Thu, Jun 26, 2008 at 5:33 PM, Guido van Rossum <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> an explanation about *why* Django cannot even be imported than a
>>> blanket complaint that this is a disgrace. So why is it?
>
>> and already discussed:
>> http://mail.python.org/pipermail/python-dev/2008-April/078421.html
>
> Following that trail of breadcrumbs, I ended up here:
>
>   http://bugs.python.org/issue2235
>
> with a message from some guy named "Barry Warsaw" (anyone know him?) that
> says:
>
>  """
>  Guido, can you comment on Amaury's latest patch?  I'm going to bump this
>  back to critical so as not to hold up 2.6 alpha, but it should be marked
>  as a release blocker for the first beta.
>  """
>
> I don't know if this "Barry" guy has the appropriate permissions on the
> bugtracker to increase priorities, so I've taken the liberty of upgrading it
> as a release blocker for the _second_ beta ... ;-).  So, at least there's
> been one productive consequence of this discussion.

this patch even make things worse for me. now py.test also dies.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

[Ralf Schmitt]

On Thu, Jun 26, 2008 at 7:55 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 26, 2008 at 10:40 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
>> this patch even make things worse for me. now py.test also dies.
>
> Please add details to the tracker.
>

Well, I think most probably the patch is correct and it just catches
another class which defines __eq__ but does not define __hash__. So
nothing to add there.
The question is if this behaviour should be kept or not. I guess
there's no bug tracking that...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

[Ralf Schmitt]

On Thu, Jun 26, 2008 at 8:45 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> So you're saying py.test needs to be fixed? Fine with me, but then I
> don't understand why you bothered bringing it up here instead of
> fixing it (or reporting to the py.test maintainers, I don't know if
> you're one or not).
>

no, I'm not. Just wanted to point out, that this ticket/patch does not
solve the django issue.
(this is what I first thought it would do).

- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] AMD64-W2k8 buildbot wedged

[Ralf Schmitt]

On Sun, Jul 13, 2008 at 6:35 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>> The compilation step on this buildbot is failing because it can't delete
>> or overwrite any of the Python DLLs [1]. Is there any way to fix this
>> remotely, or at least to tell why kill_python isn't doing the trick?
>
> That is in the log:
>
> TerminateProcess failed: 5
>
> where 5 is ERROR_ACCESS_DENIED. Now, *why* the system is refusing to
> terminate the process is difficult to say. It's a general Windows
> problem: the system doesn't support forced process termination in a
> reliable manner.
>
> In any case, Trent seems to have fixed the problem.
>
>> The number of 64-bit safeness
>> warnings being emitted by the current trunk is also fairly worrying)
>
> Do you have a specific one in mind? The ones truncating size_t/ssize_t
> should only matter when you actually do have data larger than 2GiB.
>

http://bugs.python.org/issue3026 comes to mind.

And I would rather use a little bit different wording: The ones
truncating size_t/ssize_t do matter, unless  you know in advance that
you will always deal with data lesser than 2GiB.
Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [ANN] VPython 0.1

[Ralf Schmitt]

On Fri, Oct 24, 2008 at 7:18 AM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> I have not seen any Windows test yet.  The direct threading is gcc-specific,
> so there might be degradation with MSVC.
>

erlang uses gcc to compile a single source file on windows and uses MS
VC++ to compile all others. They also need the gcc labels-as-values
extension and the file in question seems to be their bytecode
interpreter (beam_emu.c).

- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Looking for VCS usage scenarios

[Ralf Schmitt]

On Mon, Nov 3, 2008 at 1:05 AM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> I have started the DVCS PEP which can be seen at
> http://docs.google.com/Doc?id=dg7fctr4_40dvjkdg64 . Not much is there
> beyond the rationale, usage scenarios I plan to use, and what other
> sections I plan to write.
>

I think you really should not exclude any dvcs based on it's
implementation language.
I.e. requiring it being written in python for the sake of "eating your
own dogfood" is just a very weak argument. git is certainly missing
from your list.

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Looking for VCS usage scenarios

[Ralf Schmitt]

On Mon, Nov 3, 2008 at 7:05 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> I have yet to have met anyone who thinks git is great while having
> used another DVCS as extensively (and I mean I have never found
> someone who has used two DVCSs extensively).

I have used mercurial extensively (before having used git) and I think
git is great.
It gives you much more freedom to work with your source code than mercurial.

- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Looking for VCS usage scenarios

[Ralf Schmitt]

On Tue, Nov 4, 2008 at 6:45 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Ralf Schmitt schrieb:
>> I think you really should not exclude any dvcs based on it's
>> implementation language.
>> I.e. requiring it being written in python for the sake of "eating your
>> own dogfood" is just a very weak argument. git is certainly missing
>> from your list.
>
> And by then, why not include darcs, GNU arch and monotone?
>

please include all of them and choose the best one. that was my point.

Regards,
- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime.date.today() raises "AttributeError: time"

[Ralf Schmitt]

On Wed, Dec 10, 2008 at 6:49 PM, James Y Knight <[EMAIL PROTECTED]> wrote:
>
> On Dec 10, 2008, at 5:55 AM, Lennart Regebro wrote:
>
>> Turns out, I created an empty time.py in /tmp, just to see the error
>> message. By buildout will when creating eggs from checked out modules,
>> copy them to a directory under /tmp, and evidently run python from
>> /tmp to create the eggs. So that process finds the time.pyc, created
>> from the empty time.py, which I hadn't deleted, and breaks!
>
> Sounds like a security hole in zc.buildout. Imagine someone *else* made a
> time.py in /tmp...
>

the current working directory is also added to sys.path if PYTHONPATH
contains an empty element. might be the case here...

- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GitHub mirror

[Ralf Schmitt]

anatoly techtonik  writes:

> On the subject. Is there a mirror of CPython on GitHub?

https://github.com/schmir/python

-- 
Cheers
Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter

[Ralf Schmitt]

Guido van Rossum  writes:

> It's like calling socket.settimeout(0.1) and then complaining that
> urllib.urlopen() raises exceptions

but that's not what's happening. you'll see urllib.urlopen raising
exceptions and only afterwards realize that you called into some third
party library code that decided to change the timeout.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter

[Ralf Schmitt]

"R. David Murray"  writes:

> On Sun, 27 Jan 2013 19:42:59 +0100, Ralf Schmitt  wrote:
>> Guido van Rossum  writes:
>> 
>> > It's like calling socket.settimeout(0.1) and then complaining that
>> > urllib.urlopen() raises exceptions
>> 
>> but that's not what's happening. you'll see urllib.urlopen raising
>> exceptions and only afterwards realize that you called into some third
>> party library code that decided to change the timeout.
>
> What is stopping some some third party library code from calling
> socket.settimeout(0.1)?

Nothing. That's the point. You just wonder why urlopen fails when the
global timeout has been changed by that third party library.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter

[Ralf Schmitt]

"R. David Murray"  writes:

> On Sun, 27 Jan 2013 21:56:06 +0100, Ralf Schmitt  wrote:
>> "R. David Murray"  writes:
>> 
>> > On Sun, 27 Jan 2013 19:42:59 +0100, Ralf Schmitt  
>> > wrote:
>> >> Guido van Rossum  writes:
>> >> 
>> >> > It's like calling socket.settimeout(0.1) and then complaining that
>> >> > urllib.urlopen() raises exceptions
>> >> 
>> >> but that's not what's happening. you'll see urllib.urlopen raising
>> >> exceptions and only afterwards realize that you called into some third
>> >> party library code that decided to change the timeout.
>> >
>> > What is stopping some some third party library code from calling
>> > socket.settimeout(0.1)?
>> 
>> Nothing. That's the point. You just wonder why urlopen fails when the
>> global timeout has been changed by that third party library.
>
> Oh, you were agreeing with Guido?  I guess I misunderstood.

no. I think it's rather surprising if your code depends on some global
variable that might change by calling into some third party code.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter

[Ralf Schmitt]

"R. David Murray"  writes:

> On Sun, 27 Jan 2013 21:56:06 +0100, Ralf Schmitt  wrote:
>> "R. David Murray"  writes:
>> 
>> > On Sun, 27 Jan 2013 19:42:59 +0100, Ralf Schmitt  
>> > wrote:
>> >> Guido van Rossum  writes:
>> >> 
>> >> > It's like calling socket.settimeout(0.1) and then complaining that
>> >> > urllib.urlopen() raises exceptions
>> >> 
>> >> but that's not what's happening. you'll see urllib.urlopen raising
>> >> exceptions and only afterwards realize that you called into some third
>> >> party library code that decided to change the timeout.
>> >
>> > What is stopping some some third party library code from calling
>> > socket.settimeout(0.1)?
>> 
>> Nothing. That's the point. You just wonder why urlopen fails when the
>> global timeout has been changed by that third party library.
>
> Oh, you were agreeing with Guido?  I guess I misunderstood.

no. I think it's rather surprising if your code depends on some global
variable that might change by calling into some third party code.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter

[Ralf Schmitt]

Guido van Rossum  writes:

> Yeah, so the answer to all this is that 3rd party libraries know better
> than to mess with global settings.

Right. But why make it configurable at runtime then? If you're changing
the value, then you're the one probably breaking third party code.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter

[Ralf Schmitt]

Guido van Rossum  writes:

>
> On Mon, Jan 28, 2013 at 1:56 PM, Ralf Schmitt  wrote:
>
>> Guido van Rossum  writes:
>>
>> > Yeah, so the answer to all this is that 3rd party libraries know better
>> > than to mess with global settings.
>>
>> Right. But why make it configurable at runtime then? If you're changing
>> the value, then you're the one probably breaking third party code.
>
> Sigh. This is getting exasperating. There's other code that might want to
> change this besides 3rd party library code. E.g. app configuration code.

So, third party library code should know better, while at the same time
it's fine to mess with global settings from app configuration code.

That does not make sense.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter

[Ralf Schmitt]

Antoine Pitrou  writes:

> Yes, it's fine, because an application developer can often control (or
> at least study) the behaviour of all the code involved.

I'd rather not have to check if some library messes with that global
setting and work around it if it does! The fact that you can control and
work around a global setting that may change, isn't a reason to
introduce that global setting and the increased complexity that comes
with it.

>
> It's the same story as with logging configuration and similar
> process-wide settings. Libraries shouldn't mess with it but the
> top-level application definitely can (and should, even).

That's a bad comparison, because the situation is quite different with
the logging module. Configuration of the logging module does not change
the behaviour for code calling into the logging module (well, besides
log output being produced somewhere, but that doesn't matter for the
caller).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter

[Ralf Schmitt]

Antoine Pitrou  writes:

> Le Tue, 29 Jan 2013 09:35:40 +0100,
> Ralf Schmitt  a écrit :
>> 
>> I'd rather not have to check if some library messes with that global
>> setting and work around it if it does!
>
> Then just don't try changing the flag. Problem solved.

I was talking about some library changing the flag. Not changing the
flag myself doesn't help in that case. I'll probably have to explicitly
pass a cloexec argument to each fd creating function I'm calling in
order to not be dependent on the global setting.

Please just acknowledge that having a global configurable setting may
lead to problems. Why is sys.setdefaultencoding being hidden in python
2?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] BDFL delegation for PEP 426 (PyPI metadata 1.3)

[Ralf Schmitt]

Daniel Holth  writes:

> Wheel makes it possible for Python to get out of the build tool
> business. Just install your preferred tools with a concise bootstrap
> installer.

If this is true, it would also have been possible with eggs, yet it
didn't happen. Why do you think it will happen now or am I missing
something?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the PEP 433?

[Ralf Schmitt]

Victor Stinner  writes:


>
> Q: The PEP may break applications.
> A: Most developers agree that it is (very) unlikely. If file
> descriptor inherance matters, subprocess must be used (because it
> rocks!) with pass_fds. 

But that doesn't cover the case for programs that don't fork and really
just want to exec another program. when using subprocess, you'll always
have two processes running.

> If subprocess is used without pass_fds,
> applications stops working since python 3.2 (since python 3.0 on
> Windows). pass_fds will clear the close-on-exec flag on the file
> descriptors with the PEP. If an application breaks because it relies
> on file descriptor inherance, it's easy to detect it (EBADF error) and

the application may open other files/sockets and the unused file
descriptor would be reused. there's no EBADF in that case.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com