On Jul 22, 2009, at 4:49 AM, M.-A. Lemburg wrote:
Debian has a long history of doing this different, so it's
not much of a surprise. They also apply such changes to
Python packages.
However, all of this is non-standard and will cause problems
with tools that rely on the standard
On Jul 21, 2009, at 7:38 PM, David Lyon wrote:
When I go into python on ubuntu I see there is /usr/local/pythonX.X/
lib/
site-packages and I'm wondering why the hubba setuptools/distutils
doesn't put packages there by default. That would solve a lot of
problems.
Just leave
On Jun 21, 2009, at 5:40 PM, Eric Smith wrote:
I've basically come to accept that %-formatting can never go away,
unfortunately. There are too many places where %-formatting is used,
for example in logging Formatters. %-formatting either has to exist
or it has to be emulated.
It'd
On May 20, 2009, at 4:07 PM, Nick Coghlan wrote:
Forcing developers to choose between the speed of the INCREF/DECREF
macros and the proposed ABI compatibility mode for the benefit of an
as
yet hypothetical GIL-less CPython API implementation seems more like a
way to kill adoption of the ABI
On May 17, 2009, at 4:54 PM, Martin v. Löwis wrote:
Currently, each feature release introduces a new name for the
Python DLL on Windows, and may cause incompatibilities for extension
modules on Unix. This PEP proposes to define a stable set of API
functions which are guaranteed to be available
On May 6, 2009, at 5:39 AM, Stephen J. Turnbull wrote:
Now, with Python's file system encoding == UTF-8 or any packed EUC,
and more than a handful of Shift JIS or Big5 characters in file names,
one is *almost certain* to encounter ASCII as the second byte of a
multibyte sequence. PEP 383 can't
On May 1, 2009, at 9:42 PM, Zooko O'Whielacronx wrote:
Yep, I reversed the order of encode() and decode(). However, my whole
statement was utterly wrong and shows that I still didn't fully get it
yet. I have flip-flopped again and currently think that PEP 383 is
useless for this use case and
On Apr 30, 2009, at 5:42 AM, Martin v. Löwis wrote:
I think you are right. I have now excluded ASCII bytes from being
mapped, effectively not supporting any encodings that are not ASCII
compatible. Does that sound ok?
Yes. The practical upshot of this is that users who brokenly use
On Apr 28, 2009, at 2:50 AM, Martin v. Löwis wrote:
James Y Knight wrote:
Hopefully it can be assumed that your locale encoding really is a
non-overlapping superset of ASCII, as is required by POSIX...
Can you please point to the part of the POSIX spec that says that
such overlapping
On Apr 27, 2009, at 11:35 PM, Martin v. Löwis wrote:
No. You seem to assume that all bytes 128 decode successfully
always.
I believe this assumption is wrong, in general:
py \x1b$B' \x1b(B.decode(iso-2022-jp) #2.x syntax
Traceback (most recent call last):
File stdin, line 1, in module
On Apr 24, 2009, at 8:00 AM, Paul Moore wrote:
However, it *does* agree with the reality of Windows file systems. The
fundamental problem here is that there is a strong OS disparity - for
Windows, the OS uses Unicode, for POSIX, the OS uses bytes.
It's unfortunately the case that this isn't
On Apr 22, 2009, at 2:50 AM, Martin v. Löwis wrote:
I'm proposing the following PEP for inclusion into Python 3.1.
Please comment.
+1. Even if some people still want a low-level bytes API, it's
important that the easy case be easy. That is: the majority of Python
applications should
On Apr 16, 2009, at 5:47 PM, Antoine Pitrou wrote:
IMHO, the question is rather what the use case is for the behaviour
you are
proposing. In which kind of situation is it acceptable to turn 31/2
silently
into 29/2?
Essentially any situation in which you'd actually want a next month
On Apr 15, 2009, at 12:15 PM, M.-A. Lemburg wrote:
The much more common use case is that of wanting to have a base
package
installation which optional add-ons that live in the same logical
package namespace.
The PEP provides a way to solve this use case by giving both
developers
and
On Apr 13, 2009, at 10:11 AM, Barry Warsaw wrote:
The email package does not need a parser for every header, but it
should provide a framework that applications (or third party
libraries) can use to extend the built-in header parsers. A bare
minimum for functionality requires a
On Apr 9, 2009, at 10:38 PM, Barry Warsaw wrote:
So, what I'm really asking is this. Let's say you agree that there
are use cases for accessing a header value as either the raw encoded
bytes or the decoded unicode.
As I said in the thread having nearly the same exact discussion on web-
On Apr 5, 2009, at 6:29 AM, Antoine Pitrou wrote:
Brian Quinlan brian at sweetapp.com writes:
I don't see why this is helpful. Could you explain why
_RawIOBase.close() calling self.flush() is useful?
I could not explain it for sure since I didn't write the Python
version.
I suppose it's
On Mar 11, 2009, at 9:06 PM, Nick Coghlan wrote:
Raymond Hettinger wrote:
The current formatting mini-language provisions left/right/center
alignment, prefixes for 0b 0x 0o, and rules on when to show the
plus-sign. I think it would be far more useful to provision a simple
way of specifying a
On Mar 11, 2009, at 11:40 PM, Nick Coghlan wrote:
Raymond Hettinger wrote:
It is not the goal to replace locale or to accomodate every
possible convention. The goal is to make a common task easier
for many users. The current, default use of the period as a decimal
point has not proven to be
On Mar 4, 2009, at 9:56 AM, Chris Withers wrote:
Vaibhav Mallya wrote:
We do have HTMLParser, but that doesn't handle malformed pages
well, and just isn't as nice as BeautifulSoup.
Interesting, given that BeautifulSoup is built on HTMLParser ;-)
I think html5lib would be a better
On Dec 11, 2008, at 11:08 AM, Jeffrey Yasskin wrote:
On Thu, Dec 11, 2008 at 1:34 AM, Victor Stinner
[EMAIL PROTECTED] wrote:
But if -as many people wrote-
Python is totally broken after a segfault, it is maybe not a good
idea :-)
While it's true that after a segfault or unexpected
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
On Dec 9, 2008, at 2:26 PM, Lars Kotthoff wrote:
Dear list,
I recently noticed a python program which uses forks and pipes for
communication between the processes not behaving as expected. The
minimal
example program:
[snip]
This prints out foo twice although it's only written once to
On Dec 5, 2008, at 5:27 AM, Ulrich Eckhardt wrote:
Using the byte variant is equally fubar, because e.g. on MS Windows
it is not
supported, except through a very lossy roundtrip through the locale's
codepage, limiting your functionality.
Yeah, IMO whole mess could have been avoided by
On Dec 5, 2008, at 7:48 PM, Nick Coghlan wrote:
You can't display a non-decodable filename to the user, hence the user
will have no idea what they're working on. Non-filesystem related apps
have no business trying to deal with insane filenames.
Sigh, same arguments, all over again.
Again,
On Dec 4, 2008, at 6:39 PM, Martin v. Löwis wrote:
I'm in favour of a different, fifth solution:
5) represent all environment variables in Unicode strings,
including the ones that currently fail to decode.
(then do the same to file names, then drop the byte-oriented
file operations
On Oct 30, 2008, at 1:31 PM, Eric Smith wrote:
Guido van Rossum wrote:
No offense taken. The V8 experience makes me feel much more
optimistic
that they might actually pull this off. (I'm still skeptical about
support for extension modules, withougt which CPython is pretty
lame.)
The
On Oct 7, 2008, at 3:47 AM, Martin v. Löwis wrote:
- Having os.getcwdb isn't much use when you can't even run python in
the first place when the current directory has bad bytes in it.
That's not true: it *is* of much use. Python will live in /usr/bin,
which has a nicely-decodable path.
On Oct 7, 2008, at 4:45 PM, Adam Olsen wrote:
So what does Qt do when given a file name already using those PUA?
Looks like they get passed through untouched when decoded, but will
get translated into invalid names upon encoding.
Well, I'd say that looks like a bug. It should probably decode
On Oct 6, 2008, at 8:52 PM, Benjamin Peterson wrote:
I'm not sure we do. Correct me if I'm wrong, but the big ticket,
issue bytes/unicode filepaths, has been resolved. And looking at the
tracker, I only see 18 release blockers.
Well, if you mean that the resolution decided upon is to simply
On Sep 30, 2008, at 5:40 PM, Martin v. Löwis wrote:
On Windows, we might reject bytes filenames for all file
operations: open(),
unlink(), os.path.join(), etc. (raise a TypeError or UnicodeError)
Since I've seen no objections to this yet: please no. If we offer a
lower-level bytes filename
On Sep 30, 2008, at 6:21 PM, Martin v. Löwis wrote:
IOW, Java hasn't solved the problem in the last 10 years.
Java is already really bad at being a small little language to write
cooperating tools in. I'd never even attempt to write a little
pipeline filter in Java -- I've already pretty
On Sep 30, 2008, at 10:06 PM, [EMAIL PROTECTED] wrote:
However, Martin, I can promise you that I will _never_ ask for any
convenience functions related to bytes as a result of this
decision. I want bytes to come back from filesystem APIs because I
intend to have a wrapper layer which
On Sep 29, 2008, at 6:17 PM, Adam Olsen wrote:
I suspect linux will eventually take this route as well. If ext3 had
an option for UTF-8 validation I know I'd want it on. That'd move the
error to the program creating bogus file names, rather than those
trying to read, display, and manage them.
On Sep 17, 2008, at 10:53 AM, Andrew MacIntyre wrote:
Martin v. Löwis wrote:
I haven't yet tried posting a query to a FreeBSD list, as it could
simply
be a bug on amd64, but I was wondering whether there was anything
(other
than deactivating tests and documenting use of ulimit -v on this
On Aug 25, 2008, at 9:52 PM, Greg Ewing wrote:
Guido van Rossum wrote:
If you call:
subprocess.call(cmd, shell=False)
Then it works on Linux, but fails on Windows because it does not
perform the Windows %PATHEXT% search that allows it to find that
svn.exe is the actual executable to be
On Aug 7, 2008, at 12:36 AM, Ian Charnas wrote:
Hello heroes and heroins of the python universe, lend me your ears and
I will tell you a tale that will make your platters spin!
As noted by SQLite [1] and MySQL [2] developers, fsync on OS X does
not actually flush a file to disk... instead OS
On Jul 3, 2008, at 10:46 AM, Jeroen Ruigrok van der Werven wrote:
-On [20080703 15:58], Guido van Rossum ([EMAIL PROTECTED]) wrote:
Your seem to be suggesting that len(u\U00012345) should return 1 on
a system that internally uses UTF-16 and hence represents this string
as a surrogate pair.
On May 21, 2008, at 11:26 AM, Michael Foord wrote:
And what about platforms like the JVM or CLR?
Incidentally there were a small but vocal group of Pythonistas who
were (are?) certain that IronPython is not Python because it doesn't
have [all of...] the C extensions.
It seems likely to
On May 21, 2008, at 3:58 PM, Jean-Paul Calderone wrote:
Plus, even if ctypes works, the code might be incorrect, because they
had been assuming structure layouts and symbolic constants that have
just a different definition on some other platform, causing the
extension module to crash.
Writing
On Apr 2, 2008, at 11:52 PM, Guido van Rossum 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
On Dec 9, 2007, at 5:52 AM, Giampaolo Rodola' wrote:
def handle_expt(self):
Like said above, this is called when arrived some OOB data.
I would change this into something like: Called when some OOB data
arrived.
Of course, that's not actually true. It's called for whatever the exc
bit
On Nov 21, 2007, at 5:58 PM, Paul Moore wrote:
Is it only me who thinks that the current daily summaries are a bit
frequent? Would it be possible to reduce the frequency to, say, once a
week?
I can set up a filter to simply ditch the things, but I thought I'd
check what other people's views
On Sep 11, 2007, at 3:30 PM, Brett Cannon wrote:
We should probably document where all of these globals lists are
instead of relying on looking for all file level static declarations
or something. Or would there be benefit to moving things like this to
the interpreter struct so that threads
On Aug 15, 2007, at 9:29 PM, Bill Janssen wrote:
I'd really like an excuse to implement server-side SSL support one of
these days. Could that be a sprint activity? Probably against 2.6 (I
doubt the Modules/_ssl.c file will change much for 3K).
The idea is that if you call socket.ssl() on
On Aug 8, 2007, at 3:47 PM, Nick Maclaren wrote:
Firstly, things like backreferences are an absolute no-no. They
are not regular, and REs with them in cannot be converted to DFAs.
That could be 'solved' by a parser that kicked out such constructions,
but it would get screams from many users.
On Jul 12, 2007, at 1:58 PM, Phillip J. Eby wrote:
I don't have any particular objection to using runpy for this, but I
believe that this shebang line won't actually work on certain non-BSD
OSes, such as most Linux versions, which allow you to have at most
*one* argument to a #! line, and will
On Jun 24, 2007, at 2:19 PM, Martin v. Löwis wrote:
I don't see why it is a requirement to *open* the file in
non-inheritable mode. Why is not sufficient to *modify*
an open file to have its handle non-inheritable in
an easy and platform-independent way?
Threads. Consider that you may fork a
On May 8, 2007, at 8:49 AM, Armin Rigo wrote:
On Tue, May 08, 2007 at 09:14:02AM +1000, Anthony Baxter wrote:
I'd like to suggest that we remove all (or nearly all) uses of
xrange from the stdlib. A quick scan shows that most of the usage
of it is unnecessary. With it going away in 3.0, and it
On Apr 29, 2007, at 9:07 PM, Greg Ewing wrote:
Guido van Rossum wrote:
Nearly always wrong? You must be kidding. There are tons of
reasons to
call your super method with modified arguments. E.g. clipping,
transforming, ...
That's a good point. Just because the *signature* is the
same
On Apr 28, 2007, at 10:43 PM, Calvin Spealman wrote:
Abstract
The PEP defines the proposal to enhance the super builtin to work
implicitly
upon the class within which it is used and upon the instance the
current
function was called on. The premise of the new super usage
On Feb 28, 2007, at 9:10 PM, Guido van Rossum wrote:
I am beginning to think that there are serious problems with attaching
the traceback to the exception; I really don't like the answer that
pre-creating an exception is unpythonic in Py3k.
I'll say up front that I haven't been paying as much
On Jan 17, 2007, at 6:22 PM, Anthony Baxter wrote:
On Wednesday 17 January 2007 05:52, James Y Knight wrote:
Yes, this is it. As a refinement: if the New Way can easily be
backported to 2.5,
Um - 2.5 is _done_. Released. In maintenance mode. New features will
not be getting backported
On Jan 12, 2007, at 7:26 PM, Ron Adam wrote:
For me, the thing that will make porting 2.x to 3.x code easy is to
make python
3.0 as clean and organized as you can with excellent
documentation. Half-way
and duel-way approaches will probably not help me as much as this.
Most of the
On Jan 15, 2007, at 8:02 AM, Thomas Wouters wrote:
The benefit (to me, and to many others) of 3.x over 2.x is the
promise
of getting rid of cruft.
If we're going to re-add cruft for the sake of temporary
compatibility, we may as well just stick with 2.x. You have to
take a
quantum leap
On Jan 16, 2007, at 12:06 PM, Phillip J. Eby wrote:
At 07:47 AM 1/16/2007 -0800, Guido van Rossum wrote:
I'm not keen on compromises in 3.0, but without specific proposals I
don't see why we're arguing. So, please, what specific thing(s) are
you proposing we do in 3.0? Please make a list of
On Jan 16, 2007, at 10:47 AM, Guido van Rossum wrote:
I'm not keen on compromises in 3.0, but without specific proposals I
don't see why we're arguing. So, please, what specific thing(s) are
you proposing we do in 3.0? Please make a list of specifics rather
than attempting at specifying a
On Jan 16, 2007, at 2:35 PM, Guido van Rossum wrote:
Mainly I'd just like to see allowing the ability to write code which
is portable between 2.5 and 3.0 as an explicit goal of the python
3.0 release. I trust that if the developers agree upon that as being
a goal, the right things would
On Jan 10, 2007, at 6:46 PM, Benji York wrote:
Paul Moore wrote:
How many other projects/packages anticipate *not* migrating to
Py3K, I wonder?
I certainly can't speak for the project as a whole, but I anticipate a
fair bit of work to port Zope 3 (100+ KLOC) to Python 3.0.
I (another
On Jan 11, 2007, at 8:12 PM, Anthony Baxter wrote:
I'm plan to try and make the transition as painless as possible.
I'm glad to hear it.
The goal is to have a first alpha sometime this year - there is
absolutely no chance of a 3.0 final this year.
Duly noted.
Basically: my plea is: please
On Nov 4, 2006, at 3:49 AM, Martin v. Löwis wrote:
Notice that at least the following objects are shared between
interpreters, as they are singletons:
- None, True, False, (), , u
- strings of length 1, Unicode strings of length 1 with ord 256
- integers between -5 and 256
How do you deal
On Oct 25, 2006, at 10:48 PM, Talin wrote:
That's true of textual paths in general - i.e. even on unix, textual
paths aren't guaranteed to be unique or exist.
Its been a while since I used classic MacOS - how do you handle things
like configuration files with path names in them?
You aren't
On Oct 3, 2006, at 8:30 AM, Martin v. Löwis wrote:
As Michael Hudson observed, this is difficult to implement, though:
You can't distinguish between -0.0 and +0.0 easily, yet you should.
Of course you can. It's absolutely trivial. The only part that's even
*the least bit* sketchy in this is
On Oct 3, 2006, at 2:26 PM, Nick Maclaren wrote:
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote:
py x=-0.0
py y=0.0
py x,y
Nobody is denying that SOME C90 implementations distinguish them,
but it is no part of the standard - indeed, a C90 implementation is
permitted
On Aug 17, 2006, at 1:26 AM, Neal Norwitz wrote:
Thanks Dino.
The attached patch should fix the problem. Once RC1 is cut, I'll
check this in unless someone beats me to it. Since the compiler
changed, I can't backport this. If someone wants to make a similar
fix for 2.4 go for it.
The
On Aug 15, 2006, at 6:20 PM, Martin v. Löwis wrote:
Guido van Rossum schrieb:
From the Python *user*'s perspective, yes, as much as possible. But
I'm still playing with the thought of having two implementation
types,
since otherwise we'd have to devote 4 bytes (8 on a 64-bit platform)
to
On Aug 15, 2006, at 7:06 PM, Guido van Rossum wrote:
There's no particular reason that a short int must be able to store
the entire range of C long, so, as many bits can be stolen from it
as desired.
There isn't? Actually a lot of APIs currently assumen that.
I thought we were talking about
On Aug 10, 2006, at 12:01 PM, Josiah Carlson wrote:
Michael Urman [EMAIL PROTECTED] wrote:
On 8/9/06, Michael Hudson [EMAIL PROTECTED] wrote:
The question doesn't make sense: in Python, you assign to a name,
an attribute or a subscript, and that's it.
Just to play devil's advocate here,
On Aug 10, 2006, at 12:19 PM, James Y Knight wrote:
Please note I'm actually arguing for this proposal. Just agreeing
that it is not a completely nonsensical idea.
ERK! Big typo there. I meant to say:
Please note I'm NOT*** actually arguing for this proposal.
Sorry for any confusion
On Aug 10, 2006, at 12:24 PM, Guido van Rossum wrote:
On 8/10/06, James Y Knight [EMAIL PROTECTED] wrote:
It makes just as much sense as assigning to an array access, and the
semantics would be pretty similar.
No. Array references (x[i]) and attribute references (x.a) represent
locations
On Aug 10, 2006, at 4:57 PM, Phillip J. Eby wrote:
However, I'm also not clear that trying to assign to a function
call *is* ill-advised. One of the things that attracted me to
Python in the first place is that it had a lot of features that
would be considered hypergeneralization in
On Aug 3, 2006, at 5:47 PM, M.-A. Lemburg wrote:
The only way this error could be the right thing is if you were
trying
to suggest that he shouldn't mix unicode and bytestrings at all.
Good question. I wonder whether that's a reasonable approach for
Python 2.x (I'd say it is for Py3k).
On Aug 3, 2006, at 2:34 AM, Greg Ewing wrote:
Raymond Hettinger wrote:
-1 on an extra built-in just to save the time for function call
The time isn't the main issue. The main issue
is that almost all the use cases for round()
involve doing an int() on it afterwards. At
least nobody has
On Aug 4, 2006, at 12:34 AM, Josiah Carlson wrote:
As an alternate idea, rather than attempting to .decode('ascii') when
strings and unicode compare, why not .decode('latin-1')? We lose the
unicode decoding error, but the right thing happens (in my opinion)
when u'\xa1' and '\xa1' compare.
On Aug 2, 2006, at 11:26 PM, Raymond Hettinger wrote:
Also, -10 on changing the semantics of int() to round instead of
truncate. The truncating version is found is so many other languages
and book examples, that it would be a disaster for us to choose a
different meaning.
I'd be happy to
On Jul 23, 2006, at 4:41 PM, Giovanni Bajo wrote:
I think Martin decided to keep VC71 (Visual Studio .NET 2003) for
another
release cycle. Given the impressive results of VC8 with PGO, and
the fact
that Visual Studio Express 2005 is free forever, I would hope as
well for
the decision
On Jul 21, 2006, at 6:18 AM, Nick Maclaren wrote:
To cut a long story short, it is impractical for a language run-time
system to call user-defined handlers with any degree of reliability
unless the compiled code and run-time interoperate carefully - I have
been there and done that many times,
On Jul 21, 2006, at 12:45 PM, Giovanni Bajo wrote:
Jason Orendorff wrote:
However, I'm also struggling to think of a case other than list vs
deque where the choice of a builtin or standard library data
structure would be dictated by big-O() concerns.
OK, but that doesn't mean the
On Jul 18, 2006, at 1:54 PM, Martin v. Löwis wrote:
Mihai Ibanescu wrote:
To follow up on my own email: it looks like, even though in some
locale
INFO.lower() != info
uINFO.lower() == info (at least in the Turkish locale).
Is that guaranteed, at least for now (for the current versions
On Jul 16, 2006, at 5:42 AM, Scott Dial wrote:
Talin wrote:
Scott Dial wrote:
Phillip J. Eby wrote:
A function's func_closure contains cell objects that hold the
variables. These are readable if you can set the func_closure
of some
function of your own. If the overall plan includes
On Jul 15, 2006, at 2:38 PM, Johan Dahlin wrote:
What I want to ask, is it possible to have a sanctioned way to
implement
a dynamic module/namespace in python?
For instance, it could be implemented to allow you to replace the
__dict__ attribute in a module with a user provided object
On Jul 15, 2006, at 3:15 PM, M.-A. Lemburg wrote:
Note that it also helps setting the default encoding
to 'unknown'. That way you disable the coercion of strings
to Unicode and all the places where this implicit conversion
takes place crop up, allowing you to take proper action (i.e.
explicit
On Jul 13, 2006, at 12:52 PM, Thomas Heller wrote:
IIUC, the buffer object was broken some time ago, but I think it has
been fixed. Can the 'status' of the buffer function be changed?
To quote the next question from the OP:
Is buffer safe to use? Is there an alternative?
My thinking
On Jun 30, 2006, at 3:05 AM, Neal Norwitz wrote:
If there are any bugs you think should be considered show stoppers,
mail them to the list and I will update the PEP.
I just submitted http://python.org/sf/1515169 for the ImportWarning
issue previously discussed here. IMO it's important.
James
On Jun 25, 2006, at 9:47 PM, James Y Knight wrote:
On Jun 24, 2006, at 1:29 PM, Ralf W. Grosse-Kunstleve wrote:
--- Jean-Paul Calderone [EMAIL PROTECTED] wrote:
I think it is safe to say that Twisted is more widely used than
anything
Google has yet released. Twisted also has a reasonably
On Jun 24, 2006, at 1:29 PM, Ralf W. Grosse-Kunstleve wrote:
--- Jean-Paul Calderone [EMAIL PROTECTED] wrote:
I think it is safe to say that Twisted is more widely used than
anything
Google has yet released. Twisted also has a reasonably plausible
technical reason to dislike this change.
On Jun 22, 2006, at 3:24 PM, Phillip J. Eby wrote:
Well, you can't def a dotted name, but I realize this isn't a
binding.
I have actually wanted to do that before. It would be nice if you
could. :)
James
___
Python-Dev mailing list
On May 1, 2006, at 8:15 AM, Nick Coghlan wrote:
1. PEP 343, 2.5 alpha 1, 2.5 alpha 2 and the discussions here have
no doubt
seriously confused the meaning of the term 'context manager' for a
lot of
people (you can certainly put me down as one such person). Anyone
not already
On Apr 26, 2006, at 4:49 PM, Guido van Rossum wrote:
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change anything
about Python any more because it will upset the oldtimers.
No, you can not make a change which has a tiny (and arguably
On Apr 19, 2006, at 3:19 PM, Phillip J. Eby wrote:
At 08:45 PM 4/19/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 09:02 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 07:15 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Why should a 3rd party extension be
On Apr 3, 2006, at 4:02 PM, Tim Peters wrote:
Using which compiler? This varies across boxes. Most obviously, on a
64-bit box all these members are 8 bytes (note that ob_refcnt is
Py_ssize_t in 2.5, not int anymore), but even on some 32-bit boxes the
long double trick only forces 4-byte
On Apr 4, 2006, at 11:41 PM, Alex Martelli wrote:
IMHO, the solution to THAT very real problem is to supply a built-in
function that catches some exceptions and maps them into suitable
return values. Simplest would be something like:
[...]
though I'm sure we can get better syntax if we turn
On Apr 3, 2006, at 3:12 PM, Neil Schemenauer wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
This would require a bit __del__ already called on an object,
but don't we have a whole word of GC-related flags?
No.
Actually there is. Kinda. Currently python's refcounting scheme uses
4 words
On Mar 29, 2006, at 1:38 PM, Martin v. Löwis wrote:
Given that Barry insists so firmly that there is a need, and that
this need arises from a significant code simplification that can
be achieved through the API, the natural conclusion is to add
the API. That, of course, assumes that you
On Feb 28, 2006, at 6:14 PM, Guido van Rossum wrote:
On 2/28/06, Greg Ewing [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
My personal goal in life right now is to stay as
far away from C++ as I can get.
so what C compiler are you using ?
Gcc, mostly. I don't mind if it's capable of
On Feb 22, 2006, at 6:35 AM, Greg Ewing wrote:
I'm thinking of convenience, too. Keep in mind that in Py3k,
'unicode' will be called 'str' (or something equally neutral
like 'text') and you will rarely have to deal explicitly with
unicode codings, this being done mostly for you by the I/O
On Feb 18, 2006, at 2:33 AM, Martin v. Löwis wrote:
I don't understand. In the rationale of PEP 333, it says
The rationale for requiring a dictionary is to maximize portability
between servers. The alternative would be to define some subset of a
dictionary's methods as being the standard and
On Feb 15, 2006, at 7:19 AM, Fuzzyman wrote:
[snip..]
I personally like the move towards all unicode strings, basically
any text where you don't know the encoding used is 'random binary
data'. This works fine, so long as you are in control of the text
source. *However*, it leaves the
On Feb 14, 2006, at 1:52 AM, Martin v. Löwis wrote:
Phillip J. Eby wrote:
I was just pointing out that since byte strings are bytes by
definition,
then simply putting those bytes in a bytes() object doesn't alter the
existing encoding. So, using latin-1 when converting a string to
Rossum wrote:
On 2/13/06, James Y Knight [EMAIL PROTECTED] wrote:
In py3k, when the str object is eliminated, then what do you have?
Perhaps
- bytes(\x80), you get an error, encoding is required. There is no
such thing as default encoding anymore, as there's no str object.
- bytes(\x80, encoding
101 - 200 of 255 matches
Mail list logo
