Eric Sumner wrote:
>> You mean something like this?:
>>
>>switch x in colours:
>> case RED:
>> # whatever
>> case GREEN:
>> # whatever
>> case BLUE:
>> # whatever
>>
>> I think Guido's right. It doesn't solve the underlying problem because the
>> compi
Eric Sumner wrote:
>> what's a "label" ?
>
> In your example, RED, GREEN, and BLUE. colours provides a mapping
> from values to labels/cases, and the switch statement provides a
> mapping from labels/cases to code. Sorry about introducing a new term
> without saying anything about it.
yeah, but
Georg Brandl wrote:
> In followup to a clpy discussion, should the docs contain
> a note that property can be used as a decorator for creating
> read-only properties?
feel free to steal the extended example and the read-only example from
the pyref wiki:
http://pyref.infogami.com/property
Martin v. Löwis wrote:
>> In developing a cPickle module for IronPython that's as compatible as
>> possible with CPython, these questions have come up:
>
> [I wish you were allowed to read the source code of Python]
on the other hand, it would be nice if someone actually used Bruce's questions
an
Georg Brandl wrote:
>> Can this be correct if from or to isn't a string object, but a
>> char buffer compatible object?
>
> May I note that this is still unresolved? I can submit a bug report
> and add it to PEP 356, too...
it's already on my todo list, but that list is full of stuff, so having
Brad Doctor wrote:
> I am not sure if this is the proper forum or means to submit something
> like this, so please forgive me and advise accordingly if I am in error.
to make sure that they don't just disappear under a zillion other mails,
patches should be submitted to the patch tracker:
Just van Rossum wrote:
> Why couldn't at least augmented assignment be implicitly rebinding? It
> has been suggested before (in the context of a rebinding operator), but
> I'm wondering, is this also off the table?
>
> def counter(num):
> def inc():
> num += 1
>
tomer filiba wrote:
> i thought avoiding a second dict lookup should be faster, but it turned out
> to be completely wrong. it's only marginally faster, but if an exception
> occurs, it's x10 slower.
maybe you should take this to comp.lang.python instead...
___
Skip Montanaro wrote:
> That's fine, so XML-RPC is slower than Gherkin. I can't run the Gherkin
> code, but my XML-RPC numbers are a bit different than yours:
>
> XMLRPC encode 0.65 seconds
> XMLRPC decode 2.61 seconds
>
> That leads me to believe you're not using any sort of C XML decode
Darryl Dixon wrote:
> Microsoft support capturing extended characters via _getch, but it requires
> making a
> second call to getch() if one of the 'magic' returns is encountered in the
> first call (0x00
> or 0xE0).
so why not do that in your python code?
> The relevant chunk of code in Pytho
Nicholas Bastin wrote:
> It's a mature product. I would hope that that would count for
> something. I've had enough corrupted subversion repositories that I'm
> not crazy about the thought of using it in a production system. I
> know I'm not the only person with this experience.
compared to Pe
Neil Schemenauer wrote:
> The PEP has been rewritten based on a suggestion by Guido to change
> str() rather than adding a new built-in function. Based on my testing, I
> believe the idea is feasible.
note that this breaks chapter 3 of the tutorial:
http://docs.python.org/tut/node5.html#SECTION
Gareth McCaughan wrote:
> It's valid C99, meaning "this is an unsigned long long".
since when does Python require C99 compilers?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
htt
Phillip J. Eby wrote:
>> Check out (and Pythonify) the ANSI M[UMPS] $PIECE(). See:
>> http://www.jacquardsystems.com/Examples/function/piece.htm
>
> As far as I can see, either you misunderstand what partition() does, or
> I'm
> completely misunderstanding what $PIECE does. As far as I can t
Michael Hoffman wrote:
> Dare I ask whether the uncompiled versions should be considered for
> removal in Python 3.0?
>
> *puts on his asbestos jacket*
there are no uncompiled versions, so that's not a problem.
if you mean the function level api, it's there for convenience. if you're
using less
Phillip J. Eby wrote:
>>both split on a given token. partition splits once, and returns all three
>>parts, while piece returns the part you ask for
>
> No, because looking at that URL, there is no piece that is the token split
> on. partition() always returns 3 parts for 1 occurrence of the toke
Tim Peters wrote:
> Anyone remember why setdefault's second argument is optional?
Some kind of symmetry with get, probably. if
d.get(x)
returns None if x doesn't exist, it makes some kind of sense that
d.setdefault(x)
returns None as well.
Anyone remember why nobody managed to come u
Raymond Hettinger wrote:
> Overall, I found that partition() usefully encapsulated commonly
> occurring low-level programming patterns. In most cases, it completely
> eliminated the need for slicing and indices. In several cases, code was
> simplified dramatically; in some, the simplification wa
Tim Peters wrote:
>> Anyone remember why nobody managed to come up with a better name
>> for setdefault (which is probably the worst name ever given to a method
>> in the standard Python distribution) ?
>
> I suggested a perfect name at the time:
>
>http://mail.python.org/pipermail/python-dev/
Ron Adam wrote:
> For cases where single values are desired, attribues could work.
>
> Slicing:
>line = line.partition(';').head
>line = line.partition('#').head
>
> But it gets awkward as soon as you want more than one.
>
>sep, port = host.partition(':').head, host.partiti
Ron Adam wrote:
> I'm not familiar with piece, but it occurred to me it might be useful to
> get attributes groups in some way. My first (passing) thought was to do...
>
> host, port = host.partition(':').(head, sep)
>
> Where that would be short calling a method to return them:
>
> hos
Phillip J. Eby wrote:
> Yep, subscripting and slicing are more than adequate to handle *all* of
> those use cases, even the ones that some people have been jumping through
> odd hoops to express:
>
> before = x.partition(sep)[0]
> found = x.partition(sep)[1]
> after = x.partition(sep
[EMAIL PROTECTED] wrote:
> As a Python programmer I'd get back what look like three strings: "http",
> ":", and "//www.python.org/". If each of them was a view onto part of the
> original string, only the last one would truly refer to a NUL-terminated
> sequence of characters. If I then wanted t
Greg Ewing wrote:
>> .piece() can be both a verb and a noun
>
> Er, pardon? I don't think I've ever heard 'piece' used
> as a verb in English. Can you supply an example sentence?
Main Entry: 2 piece
Function: transitive verb
Inflected Form(s): pieced; piec·ing
1 : to repair, renew, or complete by
Charles Cazabon wrote:
> in fact, it does nothing for the program but merely has the interesting
> side-effect of writing to stdout.
yeah, real programmers don't generate output.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
[EMAIL PROTECTED] wrote:
>Fredrik> Python strings are character buffers with a known length, not
>Fredrik> null-terminated C strings. the CPython implementation
>Fredrik> guarantees that the character buffer has a trailing NULL
>Fredrik> character, but that's mostly to make it eas
Paul F. Dubois wrote:
> Remove the print statementI laughed until my sides hurt. Hello? Try
> dating girls and talking to normal people, geek boys.
>
> We scientists still use these for debugging. We never 'move on' very far
> from the tutorial. The salient feature about print statements is th
Neil Hodgson wrote:
> Interactive use is its own mode and works differently to the base
> language. To print the value of something, just type an expression.
> Python will evaluate and print the value of the expression. Much
> easier than adding 'print '.
print and "echo" prints different thing
Steven Bethard wrote:
> But that would be just as easy with a print() function. In the current
> syntax:
>
>print 'foo:', foo, 'bar:', bar, 'baz:', baz,
>print 'frobble', frobble
>
> In my proposed function:
>
>print('foo:', foo, 'bar:', bar, 'baz:', baz,
> 'frobble', frobbl
Paul Moore wrote:
> Sorry about that - I just get a bit tired of feeling like everyone's
> characterising me as either a newbie, or as not writing "real" code...
Hey, I'm a newbie, and I only write simple things, but Python is for people
like me, too!
___
Steven Bethard wrote:
>> - Error and help messages, often with print >>sys.stderr
>
> Use the print() method of sys.stderr:
>
>sys.stderr.print('error or help message')
so who's going to add print methods to all file-like objects?
___
Python-D
Steven Bethard wrote:
>
>> > Use the print() method of sys.stderr:
>> >
>> >sys.stderr.print('error or help message')
>>
>> so who's going to add print methods to all file-like objects?
>
> The same people that added __iter__(), next(), readline(), readlines()
> and writelines() to their file-l
Guido van Rossum wrote:
> I also notice that _compile() is needlessly written as a varargs
> function -- all its uses pass it exactly two arguments.
that's because the function uses [1] the argument tuple as the cache key,
and I wanted to make the "cache hit" path as fast as possible.
(but that
Am I the only who are getting mails from "iextream at naver.com"
whenever I post to python-dev, btw?
My Korean (?) isn't that good, so I'm not sure what they want...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
Edward C. Jones write:
> Here is an example from the "Python Library Reference", Section 2.1
> "Built-in Functions":
>
> class C(object):
> def getx(self): return self.__x
> def setx(self, value): self.__x = value
> def delx(self): del self.__x
> x = property(getx, setx, delx, "I'm
[EMAIL PROTECTED] wrote:
>Greg> If a Python function is clearly wrapping a C function, one doesn't
>Greg> expect to be able to pass strings with embedded NULs to it.
>
> Isn't that just floating an implementation detail up to the programmer (who
> may
> well not be POSIX- or Unix-aware)?
Greg Ewing wrote:
>> (you completely missed the point -- today's print mechanism works on *any*
>> object
>> that implements a "write" method, no just file objects. saying that "oh,
>> all you need is
>> to add a method" or "here's a nice mixin" doesn't give you a print
>> replacement)
>
> Whi
Greg Ewing wrote:
> Indeed, Python's bytecode compiler essentially *is*
> a one-pass compiler
for a suitable setting of the "look-ahead window size", at least. some Python
constructs cannot be compiled by a truly minimalistic one-pass compiler.
_
putting on my "on the other hand" hat for a moment...
:::
Guido van Rossum wrote:
> 1. It's always been there
> 2. We don't want to type parentheses
> 3. We use it a lot
> 4. We don't want to change our code
there's also:
5. A reserved word makes it easy to grep for (e.g. to weed out
debugging
Kay Schluehr wrote:
> In the context of my proposal it seems to imply some variation of
> Einsteins famous sentence: "Make everything as general as possible but
> not more general" or "Make everything as powerfull as possible but not
> more powerfull".
I prefer McGrath's variation:
"Things s
Josiah Carlson wrote:
> Perhaps a bit into the future, extending import semantics to notice .pyx
> files, compare their checksum against a stored md5 in the compiled
> .pyd/.so, and automatically recompiling them if they (or their includes)
> have changed: +10 (I end up doing this kind of thing by
Greg Ewing wrote:
> Maybe backquotes could be repurposed in Py3k for interpolated
> string literals?
backquotes are a PITA to type on many non-US keyboards.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
Antoine Pitrou wrote:
> - seamless unicode support: how about making the default Python
> charset utf-8 instead of ascii ? right now, someone (say an American or
> English) who does not design his app with non-ascii characters in mind
> may have a surprise when users enter those characters in cus
Martin v. Löwis wrote:
> Alternatively, couldn't LIST_APPEND check that this really is a list,
> and, if it isn't, fall back to PyObject_CallMethod?
that's the obvious solution, of course. cf. existing shortcuts:
$ grep -n INLINE Python-2.4.1/Python/ceval.c
1103: /* IN
Phillip J. Eby wrote:
> I think this is called a "polymorphic inline cache", although it doesn't
> seem very polymorphic if you're only caching one type. :)
if it's not polymorphic, it's an ordinary inline cache (aka "call-site cache").
(see various Self papers for more on polymorphic caches)
Rich Burridge wrote:
> I'm involved with the team that's working towards installing Python 2.4.x
> as part of a future release of the Solaris O/S.
>
> We currently have Python 2.3.x installed. We are trying to determine just
> how compatible these two release are (at both the binary and source lev
(oops. trying again)
Rich Burridge wrote:
> I'm involved with the team that's working towards installing Python 2.4.x
> as part of a future release of the Solaris O/S.
>
> We currently have Python 2.3.x installed. We are trying to determine just
> how compatible these two release are (at both the
Karl Chen wrote:
> Hi, has anybody considered adding something like this:
> a = [1, 2]
> [ 'x', *a, 'y']
>
> as syntactic sugar for
> a = [1, 2]
> [ 'x' ] + a + [ 'y' ].
>
> Notes:
> - This is a common operation
is it?
___
Python-De
Michael Hudson wrote:
>> While you're at it, maybe we should switch to && and || as well?
>> That's another thing I always mistype when switching between
>> languages...
>
> You're joking, surely?
for Python 3000, I'd recommend switching to "and then" and "or else" instead
of the current ambiguou
Phillip J. Eby wrote:
>>It is so simple to write application server in Python.
>>It is so difficult to make it scallable in CPython.
>
> It seems you've never heard of fork(), which works just fine to scale
> Python processes on multiprocessor boxes.
there's a version of fork hidden somewhere in
Guido van Rossum wrote:
> It has always been my choice to *only* use XXX. I hope there aren't
> any developers contributing to the Python core who use any others?
[Python-2.4.1]$ grep FIXME */*.c */*.py | wc -l
12
[Python-2.4.1]$ grep TODO */*.c */*.py | wc -l
17
[Python-2.4.1]$ grep XX
Guido van Rossum wrote:
> I think they all looks great!
expression if expression?
looks like you've been doing too much Perl hacking lately ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
M.-A. Lemburg wrote:
> * Unicode variant (UCS2, UCS4)
don't forget the "Py_UNICODE is wchar_t" subvariant.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
Guido van Rossum wrote:
> "Containerish" behavior isn't enough to warrant empty <--> false; in
> some sense every object is a container (at least every object with a
> __dict__ attribute) and you sure don't want to map __len__ to
> self.__dict__.__len__...
the ElementTree experience shows that do
Antoine Pitrou wrote:
> A good rule of thumb is to convert to unicode everything that is
> semantically textual
and isn't pure ASCII.
(anyone who are tempted to argue otherwise should benchmark their
applications, both speed- and memorywise, and be prepared to come
up with very strong arguments
Antoine Pitrou wrote:
> > > A good rule of thumb is to convert to unicode everything that is
> > > semantically textual
> >
> > and isn't pure ASCII.
>
> How can you be sure that something that is /semantically textual/ will
> always remain "pure ASCII" ?
"is" != "will always remain"
__
Jim Fulton wrote:
> I would argue that it's evil to change the default encoding
> in the first place, except in this case to disable implicit
> encoding or decoding.
absolutely. unfortunately, all attempts to add such information to the
sys module documentation seem to have failed...
(last time
Josiah Carlson wrote:
> > > and isn't pure ASCII.
> >
> > How can you be sure that something that is /semantically textual/ will
> > always remain "pure ASCII" ? That's contradictory, unless your software
> > never goes out of the anglo-saxon world (and even...).
>
> Non-unicode text input widgets
Antoine Pitrou wrote:
> > Under the default encoding (and quite a few other encodings), that's true
> > for
> > plain ascii strings and Unicode strings.
>
> If I have an unicode string containing legal characters greater than
> 0x7F, and I pass it to a function which converts it to str, the
> con
Antoine Pitrou wrote:
> > > If I have an unicode string containing legal characters greater than
> > > 0x7F, and I pass it to a function which converts it to str, the
> > > conversion fails.
> >
> > so? if it does that, it's not unicode safe.
> [...]
> > what's that has to do with
> > my argument
James Y Knight wrote:
> Your point would be much easier to stomach if the "str" type could
> *only* hold 7-bit ASCII.
why? strings are not mutable, so it's not like an ASCII string will suddenly
sprout
non-ASCII characters. what ends up in a string is defined by the string
source. if
you can
Nick Coghlan wrote:
> 9. Here's a proposed native context manager for decimal.Context:
>
> # This would be a new decimal.Context method
> @contextmanager
> def __with__(self):
wouldn't it be better if the ContextWrapper class (or some variation thereof)
could
be used
Nick Coghlan wrote:
> That's not what the decorator is for - it's there to turn the generator used
> to implement the __with__ method into a context manager, rather than saying
> anything about decimal.Context as a whole.
possibly, but using a decorated __with__ method doesn't make much
sense if
Martin Maly wrote:
> I came across a case which I am not sure if by design or a bug in Python
> (Python 2.4.1 (#65, Mar 30 2005, 09:13:57)). Consider following Python
> module:
>
> # module begin
> "module doc"
>
> class c:
> print __doc__
> __doc__ = "class doc" (1)
> print __doc__
>
Calvin Spealman wrote:
> I mean, come on, its like making a module just to store a bunch of
> unrelated types just to lump them together because they're types.
import types
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
Guido van Rossum wrote:
> BTW, Queue.Queue violates a recent module naming standard; it is now
> considered bad style to name the class and the module the same.
> Modules and packages should have short all-lowercase names, classes
> should be CapWords. Even the same but different case is bad style
Guido van Rossum wrote:
> > > BTW, Queue.Queue violates a recent module naming standard; it is now
> > > considered bad style to name the class and the module the same.
> > > Modules and packages should have short all-lowercase names, classes
> > > should be CapWords. Even the same but different c
Antoine Pitrou wrote:
> > unfortunately, this standard seem to result in generic "spamtools" modules
> > into which people throw everything that's even remotely related to "spam",
> > followed by complaints about bloat and performance from users, followed by
> > various more or less stupid attempt
Guido van Rossum wrote:
> OK, so how's this for a radical proposal.
>
> Let's change the property built-in so that its arguments can be either
> functions or strings (or None). If they are functions or None, it
> behaves exactly like it always has.
>
> If an argument is a string, it should be a me
Alan McIntyre wrote:
> When running "make test" I get some errors in test_array and
> test_compile that did not occur in the build from CVS. Given the inputs
> to long() have '.' characters in them, I assume that these tests really
> should be failing as implemented, but I haven't dug into them t
Guido van Rossum wrote:
> A concern I'd have with fixing this is that Unicode objects also
> support the buffer API. In any situation where either str or unicode
> is accepted I'd be reluctant to guess whether a buffer object was
> meant to be str-like or Unicode-like. I think this covers all the
M.-A. Lemburg wrote:
> I don't follow you here. The source code encoding
> is only applied to Unicode literals (you are using string
> literals in your example). String literals are passed
> through as-is.
however, for Python 3000, it would be nice if the source-code encoding applied
to the *enti
[EMAIL PROTECTED] wrote:
> I tried "svn up" to bring my sandbox up-to-date and got this output:
>
> % svn up
> UInclude/unicodeobject.h
> subversion/libsvn_wc/update_editor.c:1609: (apr_err=155017)
> svn: Checksum mismatch for
> 'Objects/.svn/text-base/unicodeobject.c.svn-base
the runtime warning you get when you use non-ascii characters in
python source code points the poor user to this page:
http://www.python.org/peps/pep-0263.html
which tells the user to add a
# -*- coding: -*-
to the source, and then provides a more detailed syntax description
as a RE pa
Brett Cannon wrote:
>I just finished fleshing out the dev FAQ
> (http://www.python.org/dev/devfaq.html) with questions covering what
> someone might need to know for regular usage. If anyone thinks I
> didn't cover something I should have, let me know.
SVK!
Jim Jewett wrote:
> (6) Mark Hammond suggests that it might be easier to
> replace the interactive portions of python based on the
> "code" module. matplotlib suggests using ipython
> instead of standard python for similar reasons.
>
> If that is really the simplest answer (and telling users
> w
Jim Jewett wrote:
> > really? Python comes with a module that makes it trivial to get
> > a fully working interpreter console ...
>
> Using an event loop (or an external GUI) should not require
> forking the entire interactive mode, no matter how trivial that
> fork is.
repeating a bogus argumen
[EMAIL PROTECTED] wrote:
> I read the developer's FAQ and the output of "svn up --help". Executing
> "svn up" or "svn info" tells me I'm already at rev 41430, which is the
> latest rev, right? Creating a fresh build subdirectory followed by
> configure and make gives me this error:
>
>../Obj
Michiel Jan Laurens de Hoon wrote:
> >Did you read my reply? ipython, based on code.py, implements a few simple
> >threading tricks (they _are_ simple, since I know next to nothing about
> >threading) and gives you interactive use of PyGTK, WXPython and PyQt
> >applications in a manner similar to
Michiel Jan Laurens de Hoon wrote:
> This is exactly the problem. Drawing one picture may consist of many
> Python commands to draw the individual elements (for example, several
> graphs overlaying each other). We don't know where in the window each
> element will end up until we have the list of
Noam Raphael wrote:
> That's a theoretical argument. In practice, if you do it in the
> parser, you have two options:
>
> 1. Automatically dedent all strings.
> 2. Add a 'd' or some other letter before the string.
>
> Option 1 breaks backwards compatibility, and makes the parser do
> unexpected th
Noam Raphael wrote:
> It didn't. Strange freezes started to appear, only when working from
> IDLE. This made me investigate a bit, and I've found that Tkinter
> isn't run from a seperate thread - the dooneevent() function is called
> repeatedly by PyOS_InputHook while the interpreter is idle.
rep
Thomas Lee wrote:
> Even if it meant we had just one function call - one, safe function call
> that deallocated all the memory allocated within a function - that we
> had to put before each and every return, that's better than what we
> have.
alloca?
(duck)
Travis Oliphant wrote:
> Bingo. Yes, definitely allocating new _types_ (an awful lot of them...)
> --- that's what the "array scalars" are: new types created in C.
are you allocating PyTypeObject structures dynamically?
why are you creating an awful lot of new type objects to represent the
cont
Travis Oliphant wrote:
> The fact that it did happen is what I'm reporting on. If nothing will
> be done about it (which I can understand), at least this thread might
> help somebody else in a similar situation track down why their Python
> process consumes all of their memory even though their o
Martin v. Löwis wrote:
> The same could be said about hotshot, which was originally contributed
> by Fred Drake, and hacked by Tim Peters, yourself, and others. Yet, now
> people want to remove it again.
>
> I'm really concerned that the same fate will happen to any new
> profiling library: anybod
Neal Norwitz wrote:
> The big benefit of running with pymalloc is that it only takes about
> 1.25 to 1.50 hours to run on my box. When running without pymalloc, I
> estimate it takes about 5 times longer. Plus it requires a lot of
> extra work since I need to run the tests in batches. I only ha
Neal Norwitz wrote:
> I think a bigger bang for the buck would be to buy a Windows box with
> Purify. Rational was a real pain to deal with, maybe it's better now
> that IBM bought them. Parasoft (Insure++) was even worse to deal
> with. There would be many other benefits for someone to do more
Neal Norwitz wrote:
> I just checked in the modification below. I'm not sure if this
> behaviour is on purpose or by accident.
Python 2.4 on Linux:
>>> float(" 0x3.1 ")
3.0625
Python 2.4 on Windows:
>>> float(" 0x3.1 ")
Traceback (most recent call last):
File "", line 1, in ?
ValueError
Gustavo Sverzut Barbieri wrote:
> At least with gentoo's Python 2.4.2, I get a bunch of errors from
> invalid reads and jumps/moves that depends on unitialized values in
> PyObject_Free().
>
> Running:
>
> valgrind --leak-check=full --leak-resolution=high --show-reachable=yes
> python -c "pass" 2
Martin v. Löwis wrote:
> One way (I think the only way) this could happen if:
> - the objects being allocated are all smaller than 256 bytes
> - when allocating new objects, the requested size was different
>from any other size previously deallocated.
>
> So if you first allocate 1,000,000 obj
Donovan Baarda wrote:
> I don't know if this will help, but in my experience compiling re's
> often takes longer than matching them... are you sure that it's the
> match and not a compile that is taking a long time? Are you using
> pre-compiled re's or are you dynamically generating strings and us
Martin v. Löwis wrote:
> Formally: no; it access a Python string/Python unicode object all
> the time.
>
> Now, since all the shared objects it accesses are immutable, likely
> no harm would be done releasing the GIL. I think SRE was originally
> also intended to operate on array.array objects; th
Jeremy Hylton wrote:
> > Me neither. Adding yet another memory allocation scheme to Python's
> > already staggering number of memory allocation strategies sounds like
> > a bad idea.
>
> The reason this thread started was the complaint that reference
> counting in the compiler is really difficult.
Nir Soffer wrote:
> However, I found this alarming note in the docs:
>
> normpath(path)
> ...
> "It should be understood that this may change the meaning of the path
> if it contains symbolic links!"
>
> The function docstring does not contain this note:
>
> """Normalize path, eliminating double s
"Delaney, Timothy (Tim)" wrote:
> > Nick Coghlan wrote:
> >> As Fredrik pointed out a while back, the PyObject approach doesn't
> >> *have* to involve manual decref operations - PyObject's come with a
> >> ready made arena structure, in the form of PyList.
> >
> > That doesn't really work: PyList_
Martin v. Löwis wrote:
> That's primarily for the author of the software to decide, at this
> point. Fredrik Lundh would have to offer it for contribution first.
I've already done that, as others have noted. Everything I release
under a Python-compatible license is available f
Martin v. Löwis wrote:
> >>That's primarily for the author of the software to decide, at this
> >>point. Fredrik Lundh would have to offer it for contribution first.
> >
> > I've already done that, as others have noted. Everything I release
> > unde
João Paulo Silva wrote:
> >>> a = file("dir/foo")
> >>> a.close()
> >>> a.read()
>
> Traceback (most recent call last):
> File "", line 1, in -toplevel-
> a.read()
> ValueError: I/O operation on closed file
>
> Shoudn't this raise IOError? Seems more semantically correct to me.
IOError is,
Martin v. Löwis wrote
> > And maybe PEP 291 could be updated to cover both compatibility with older
> > Python versions and other compatibility issues.
>
> So what would be the minimum Python version you keep compatibility with?
as Brett pointed out, the procedure to use for externally developed
501 - 600 of 732 matches
Mail list logo
