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.
T
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
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
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. P
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
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.
>>
>> Righ
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.
_
"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:
>> &g
"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:
>> &g
"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
>>
>>
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 dec
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:
htt
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 d
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 o
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.e
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 th
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
_
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,
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
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 yo
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 certa
"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 p
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
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.
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 l
"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
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 di
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 you
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 ha
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 t
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. The
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 i
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
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.
>
W
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 di
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
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
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
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
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://bu
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 docu
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 (o
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 ju
> >
> > 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 docume
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 app
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
> > re
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
>
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 buffe
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.p
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/e9446
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
__
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
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
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
__
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
> val
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 "f
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 wh
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
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
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
listenin
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 con
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 automatical
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
> > instea
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 al
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 e
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
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 duplicate
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 is
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 m
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
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
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
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
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
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
_
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
___
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 -
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 rand
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 stu
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 o
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.setdef
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
>
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
>
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 ca
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 mai
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
86 matches
Mail list logo
