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 candidat
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 pr
On Apr 5, 2009, at 6:29 AM, Antoine Pitrou wrote:
Brian Quinlan 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 so that
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-
sig
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 Content-Type
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 users
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"
oper
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 *just
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 *pr
On Apr 24, 2009, at 6:05 PM, Paul Moore wrote:
- Windows systems where broken Unicode (lone surrogates or whatever)
isn't involved
- Unix systems where the user's stated filesystem encoding is correct
Can you honestly say that this isn't the vast majority of real-world
environments? (IIRC, you a
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 "", line 1, in
Unicode
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 is
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
"ja_JP.SJI
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 th
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 h
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 f
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 co
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 possibly
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 /usr/lib/pythonX.X//l
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 site-packages/
On Jul 24, 2009, at 1:31 AM, Edward Peschko wrote:
all,
I'I was wondering if there was a command line python debugger that was
able to attach to an existing process. I'd very much like to be able
to debug over a ssh session using screen.
Ed
(ps - and yes, I know about winpdb, etc... that is
On Sep 2, 2009, at 6:15 AM, Rob Cliffe wrote:
So - the syntax restriction seems not only inconsistent, but
pointless; it doesn't forbid anything, but merely means we have to
do it in a slightly convoluted (unPythonesque) way. So please,
Guido, will you reconsider?
Indeed, it's a silly in
On Sep 18, 2009, at 3:55 PM, MRAB wrote:
I think that this should be an invariant:
0 <= file pointer <= file size
so the file pointer might sometimes have to be moved.
As for the question of whether 'truncate' should be able to lengthen a
file, the method name suggests no; if the method
On Sep 18, 2009, at 8:58 PM, Antoine Pitrou wrote:
I'm not sure that's true. Various Unix/Linux man pages are readily
available on the Internet, but they regard specific implementations,
which often depart from the spec in one way or another. POSIX specs
themselves don't seem to be easily reachab
On Sep 27, 2009, at 4:20 AM, Pascal Chambon wrote:
Thus, at the moment IOErrors rather have the semantic of "particular
case of OSError", and it's kind of confusing to have them remain in
their own separate tree... Furthermore, OSErrors are often used
where IOErrors would perfectly fit, eg.
On Sep 27, 2009, at 3:18 PM, Peter Moody wrote:
administrators) would use it, but it's doable. what you're claiming is
that my use case is invalid.
that's what I claim is broken.
He's claiming your solution to address your use case is confusing, not
that the use case is invalid.
I'm not
On Sep 28, 2009, at 4:25 AM, M.-A. Lemburg wrote:
Distributions should really not be put in charge of upstream
coding design decisions.
I don't think you can blame distros for this one
From PEP 0261:
It is also proposed that one day --enable-unicode will just
default to the width o
I'm resending a message I sent in June, since it seems the same thread
has come up again, and I don't believe anybody actually responded
(positively or negatively) to the suggestion back then.
http://mail.python.org/pipermail/python-dev/2009-June/090176.html
On Jun 21, 2009, at 5:40 PM, Eric
On Sep 30, 2009, at 10:34 AM, Steven D'Aprano wrote:
E.g.
x = newstyle_formatstr("{} {} {}")
x % (1,2,3) == x.format(1,2,3) == "1 2 3"
Moving along, let's suppose the newstyle_formatstr is introduced.
What's
the intention then? Do we go through the std lib and replace every
call
to (say)
On Oct 1, 2009, at 9:11 AM, Paul Moore wrote:
This seems to me to be almost the same as the previous suggestion of
having a string subclass:
class BraceFormatter(str):
def __mod__(self, other):
# Needs more magic here to cope with dict argument
return self.format(*other)
__ =
On Sep 30, 2009, at 1:01 PM, Antoine Pitrou wrote:
Why not allow logging.Formatter to take a callable, which would in
turn call the
callable with keyword arguments?
Therefore, you could write:
logging.Formatter("{asctime} - {name} - {level} - {msg}".format)
and then:
logging.critical(name
On Oct 1, 2009, at 5:54 PM, Nick Coghlan wrote:
I believe classes like fmt_braces/fmt_dollar/fmt_percent will be
part of
a solution, but they aren't a complete solution on their own. (Naming
the three major string formatting techniques by the key symbols
involved
is a really good idea though
On Oct 1, 2009, at 6:19 PM, Steven Bethard wrote:
I see how this could allow a user to supply a {}-format string to an
API that accepts only %-format strings. But I still don't see the
transition strategy for the API itself. That is, how does the %-format
API use this to eventually switch to {}-f
On Oct 2, 2009, at 2:56 PM, Raymond Hettinger wrote:
Do the users get any say in this?
I imagine that some people are heavily invested in %-formatting.
Because there has been limited uptake on {}-formatting (afaict),
we still have limited experience with knowing that it is actually
better, less
On Oct 5, 2009, at 2:21 PM, Brett Cannon wrote:
I should also mention this bug was not unknown. I discovered it
after Distribute 0.6 was released as I always run cutting edge
interpreters. Never bothered to report it until Distribute 0.6.1 was
released which Tarek fixed in less than a week.
On Oct 22, 2009, at 11:04 AM, Barry Warsaw wrote:
On Oct 22, 2009, at 10:47 AM, Benjamin Peterson wrote:
2009/10/22 Barry Warsaw :
So does anybody else think bug 7183 should be a release blocker
for 2.6.4
final, or is even a legitimate but that we need to fix?
I think it cannot hold up a
On Oct 22, 2009, at 3:53 PM, Robert Collins wrote:
On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote:
...
That being said, I can't this bug as a release blocker: people can
either upgrade to super-current Boost, or stick with 2.6.2 until
they can.
Thats the challenge Ubuntu faces:
http
On Oct 25, 2009, at 2:50 AM, Terry Reedy wrote:
Alex Martelli wrote:
Next(s) would seem good...
That does not work. It has to be next(iter(s)), and that has been
tried and eliminated because it is significantly slower.
But who cares about the speed of getting an arbitrary element from a
On Nov 2, 2009, at 6:24 PM, sstein...@gmail.com wrote:
+1 on 2.7 being the last of the 2.x series. Enough already!
-1. (not that it matters)
I, personally, haven't even written my first line of 3.x code, nor
have I had any good reason to.
Me neither.
If I saw the actual end of
On Nov 3, 2009, at 12:06 AM, Guido van Rossum wrote:
Though I imagine what
it really needs is a "quirks mode" parser that is compatible with the
HTML dialect accepted by, say, IE6. Maybe a summer of code project?
Already exists: html5lib.
http://code.google.com/p/html5lib/
Or if you want a fa
On Nov 3, 2009, at 8:55 AM, sstein...@gmail.com wrote:
And, as you point out, if 3.x doesn't start getting the crap beat
out of it in the real world sooner rather than later, we may find
ourselves, collectively with a stale 2.x, an under battle-tested
3.x, and nowhere to go.
If that happen
On Nov 5, 2009, at 6:04 PM, geremy condra wrote:
Perhaps my test is flawed in some way?
Yes: you're testing the speed of something that makes absolutely no
sense to do in a tight loop, so *who the heck cares how fast any way
of doing it is*!
Is this thread over yet?
James
___
On Nov 12, 2009, at 4:11 PM, Ben Finney wrote:
I think Jesse's point (or, if he's not willing to claim it, my
point) is
that, compared to the mandatory comment system, it makes much *more*
sense to have a mandatory field for “URL to the BTS for this project”.
One might look at the "competiti
On Nov 12, 2009, at 5:23 PM, Masklinn wrote:
On 12 Nov 2009, at 22:53 , James Y Knight wrote:
On Nov 12, 2009, at 4:11 PM, Ben Finney wrote:
I think Jesse's point (or, if he's not willing to claim it, my
point) is
that, compared to the mandatory comment system, it makes much *m
On Dec 1, 2009, at 11:08 AM, Martin v. Löwis wrote:
>>> I'd rather prefer to explicitly list what CPython assumes about the
>>> outcome of specific operations. If this is just about &, |, ^, and ~,
>>> then its fine with me.
>>
>> I'm not even interested in going this far:
>
> I still am: with
On Jan 7, 2010, at 3:27 PM, Martin v. Löwis wrote:
I've been wondering whether it's possible to release the GIL in the
regex engine during matching.
I don't think that's possible. The regex engine can also operate on
objects whose representation may move in memory when you don't hold
the GIL (
On Jan 8, 2010, at 4:14 PM, Tres Seaver wrote:
I understood this proposal as a general processing guideline, not
something the io library should do (but, say, a text editor).
FWIW, I'm personally in favor of using the UTF-8 signature. If people
consider them crazy talk, that may be because UTF-8
On Jan 19, 2010, at 11:07 AM, Barry Warsaw wrote:
On Jan 19, 2010, at 03:50 PM, Vinay Sajip wrote:
When I look at the mailing list archive for python-dev, I see some
odd stuff at
the bottom of the page:
http://mail.python.org/pipermail/python-dev/2010-January/thread.html#95232
Anyone know
On May 5, 2010, at 8:22 AM, Barry Warsaw wrote:
On May 5, 2010, at 7:09 AM, Oleg Broytman wrote:
On Wed, May 05, 2010 at 11:43:45AM +0100, Michael Foord wrote:
http://mail.python.org/pipermail/python-list/2000-July/108893.html
which are broken
Pipermail's links aren't stable AFAIU. The n
On May 12, 2010, at 9:13 AM, Jesus Cea wrote:
Short history: new GCC 4.5.0 (released a month ago), when compiling
with
- -O3, is adding MMX/SSE instructions that requires stack aligned to
16
byte. This is wrong, since x86 ABI only requires stack aligned to 4
bytes.
If you compile EVERYTHI
On May 12, 2010, at 10:01 AM, Jesus Cea wrote:
On 12/05/10 15:39, James Y Knight wrote:
While assuming the stack is 16byte aligned is undeniably an
ABI-violation in GCC, at this point, it's surely simpler to just go
along: the new unofficial ABI for x86 is that the stack must always
be
On Jun 21, 2010, at 4:29 PM, M.-A. Lemburg wrote:
Here's a little known fact: by changing the Python2 default
encoding to 'undefined' (yes, that's a real codec !), you can disable
all automatic string coercion in Python2.
I tried that once: half the stdlib stops working if you do (for
example
On Jun 22, 2010, at 1:03 PM, Ian Bicking wrote:
Similarly I'd expect (from experience) that a programmer using
Python to want to take the same approach, sticking with unencoded
data in nearly all situations.
Yeah. This is a real issue I have with the direction Python3 went: it
pushes you
On Jun 22, 2010, at 5:14 PM, Craig Younkins wrote:
I suggest rewording the documentation for the method making it more
clear what it should and should not be used for. I would like to see
the method changed to properly escape single-quotes, but if it is
not changed, the documentation shoul
On Jun 24, 2010, at 5:53 PM, Scott Dial wrote:
On 6/24/2010 5:09 PM, Barry Warsaw wrote:
What use case does this address?
Specifically, it's the use case where we (Debian/Ubuntu) plan on
installing
all Python 3.x packages into /usr/lib/python3/dist-packages. As of
PEP 3147,
we can do th
On Jun 25, 2010, at 4:53 AM, Scott Dial wrote:
On 6/24/2010 8:23 PM, James Y Knight wrote:
On Jun 24, 2010, at 5:53 PM, Scott Dial wrote:
If the package has .so files that aren't compatible with other
version
of python, then what is the motivation for placing that in a shared
loc
On Jun 26, 2010, at 4:35 PM, Matthias Klose wrote:
On 26.06.2010 22:30, C. Titus Brown wrote:
On Sat, Jun 26, 2010 at 10:25:28PM +0200, Matthias Klose wrote:
On 25.06.2010 02:54, Ben Finney wrote:
James Y Knight writes:
Really, python should store the .py files in /usr/share/python
On Aug 24, 2010, at 10:26 AM, Benjamin Peterson wrote:
2010/8/24 P.J. Eby :
At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote:
a) a "business" case of throwing anything other than
AttributeError from
__getattr__ and friends is almost certainly a bug waiting to
happen, and
FYI, best prac
On Aug 29, 2010, at 8:16 AM, Nick Coghlan wrote:
> However, since even platforms other than Windows aren't immune to
> version upgrades of the standard C runtime
Aren't they? I don't know of any other platform that lets you have two versions
of libc linked into a single address space. Linux has h
On Sep 24, 2010, at 10:53 AM, Paul Moore wrote:
> On 24 September 2010 15:29, Guido van Rossum wrote:
>> I don't think we should try to reimplement what the filesystem does. I
>> think we should just ask the filesystem (how exactly I haven't figured
>> out yet but I expect it will be more OS-speci
On Sep 26, 2010, at 7:36 AM, Paul Moore wrote:
> On 26 September 2010 09:01, Paul Moore wrote:
>> On 25 September 2010 23:57, Greg Ewing wrote:
>>> Paul Moore wrote:
>>>
Windows has (I believe) user definable filesystems, too, but the OS
has "get me the real filename" style calls,
>>
On Oct 3, 2010, at 9:18 AM, Dan Villiom Podlaski Christiansen wrote:
> A simpler alternative would probably be the F_GETPATH fcntl. An example:
That requires that you have permission to open the file (and to actually do so
which might have other effects), while the File Manager's FSRef method doe
On Oct 8, 2010, at 5:24 PM, Gisle Aas wrote:
> On Oct 8, 2010, at 9:22 , Jeroen Ruigrok van der Werven wrote:
>
>> +1 from me. I sincerely dislike the Perl-esque -m stuff.
>
> As a Perl/Python guy I have to object to calling the -m stuff Perl-esque.
> This is a very Pythonish thing. In the P
On Oct 19, 2010, at 1:47 PM, exar...@twistedmatrix.com wrote:
> Adding more platform wrappers is always nice. Keep in mind that the quality
> of most (all?) aio_* implementations is spotty at best, though. On Linux,
> they will sometimes block (for example, if you fail to align buffers
> prop
On Oct 19, 2010, at 6:44 PM, Martin v. Löwis wrote:
>> So, in conclusion, I disagree that adding wrappers for these would be
>> nice. It wouldn't. It would cause some people to think they would be
>> useful things to call, and they would always be wrong.
>
> We are all consenting adults. If peopl
On Oct 27, 2010, at 10:22 PM, Kristján Valur Jónsson wrote:
> Hello all.
>
> So, python 2.7 is in bugfix only mode. ‘trunk’ is off limit. So, where does
> one make improvements to the distinguished, and still very much alive, 2.x
> series of Python?
> The answer would seem to be “one doesn’
On Nov 3, 2010, at 11:25 AM, Eric Smith wrote:
> On 11/3/10 10:53 AM, Eric Smith wrote:
>
>> The problem is that there is no unittest.loader in 2.4, and
>> unittest.loader.TestLoader is the name that the 2.7 pickle creates. We
>> see this problem every time we try and move anything in the stdlib
On Nov 4, 2010, at 8:43 PM, Stephen J. Turnbull wrote:
> All of the Arch users I know expect Arch to occasionally do radical
> things because they're the right things to do in the long run.
But the previous consensus (at least, as I, and presumably many other people
understood it) was that pytho
On Nov 6, 2010, at 9:41 AM, Martin v. Löwis wrote:
> So I don't recall a decision that there shouldn't be a python2
> binary,
The decision to make one would have to be an active decision, since Python has
never installed one before. If there should be one, then the Python Makefile
should make on
On Nov 8, 2010, at 4:42 AM, Lennart Regebro wrote:
> Except for making releases that start backporting Python 3 features
> and breaking backwards compatibility gradually (which may or may not
> be a good idea) I don't see the point. There isn't much to do when it
> comes to improving the language,
On Nov 8, 2010, at 6:08 PM, Lennart Regebro wrote:
> 2010/11/8 James Y Knight :
>> On Nov 8, 2010, at 4:42 AM, Lennart Regebro wrote:
>>> So it can be done, but the question is "Why?"
>>
>> To keep the batteries included?
>
> But they'll
On Nov 10, 2010, at 8:47 AM, Michael Foord wrote:
> How about making this explicit (either pep 8 or our developer docs):
>
> If a module or package defines __all__ that authoritatively defines the
> public interface. Modules with __all__ SHOULD still respect the naming
> conventions (leading un
On Nov 13, 2010, at 7:08 AM, Antoine Pitrou wrote:
> Funny, it shows that the NNTP SSL tests don't check the certificate,
> then.
Unsurprising, given that you need 140 lines of pretty non-obvious python code
to do so...
James
___
Python-Dev mailing lis
On Nov 17, 2010, at 9:19 AM, Nick Coghlan wrote:
> (and is a little trickier in the case of module level globals, since those
> can't be deprecated properly)
People keep saying this, but there have already been examples shown of how to
do it. I actually think that python should include a way to
On Nov 17, 2010, at 10:30 AM, Guido van Rossum wrote:
> On Wed, Nov 17, 2010 at 7:24 AM, James Y Knight wrote:
>> On Nov 17, 2010, at 9:19 AM, Nick Coghlan wrote:
>>> (and is a little trickier in the case of module level globals, since those
>>> can't be depreca
On Nov 17, 2010, at 11:38 AM, Guido van Rossum wrote:
> Deprecation doesn't *require* logging a warning or raising an
> exception. You can also add a note to the docs, or if it is
> undocumented, just add a comment to the code. (Though if it is in
> widespread use despite being undocumented, a bett
Why don't ya'll just call them "--unichar-width=16/32". That describes
precisely what the options do, and doesn't invite any quibbling over
definitions.
James
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
On Nov 23, 2010, at 6:49 PM, Greg Ewing wrote:
> Maybe Python should have used UTF-8 as its internal unicode
> representation. Then people who were foolish enough to assume
> one character per string item would have their programs break
> rather soon under only light unicode testing. :-)
You put a
On Nov 24, 2010, at 12:07 AM, Stephen J. Turnbull wrote:
> Or you can give user programs memory indicies, and enjoy the fun as
> the poor developers do things like "pos += 1" which works fine on
> the ASCII data they have lying around, then wonder why they get
> Unicode errors when they take substr
On Nov 24, 2010, at 12:07 AM, Stephen J. Turnbull wrote:
> By the way, to send the ball back into your court, I have this feeling
> that the demand for UTF-8 is once again driven by native English
> speakers who are very shortly going to find themselves, and the data
> they are most familiar with,
On Nov 29, 2010, at 8:58 AM, Nick Coghlan wrote:
> The http read only URLs
> didn't work (no diff returned, just "svn: OPTIONS of
> 'http://svn.python.org/python/branches/pep-0384': 200 OK
> (http://svn.python.org)"),
That was the wrong url: you should've used
http://svn.python.org/projects/py
On Dec 1, 2010, at 11:45 PM, Alexander Belopolsky wrote:
> On Tue, Nov 30, 2010 at 3:13 PM, Antoine Pitrou wrote:
>>
>> Oh, about ICU:
>>
Actually, I remember you saying that locale should ideally be replaced
with a wrapper around the ICU library.
>>>
>>> By that, I stand - however,
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 th
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.
> expl
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
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 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"
>>
>> u"INFO".lower() == "info" (at least in the Turkish locale).
>>
>> Is that guaranteed, at least for now (for
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 tim
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
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 dec
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 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 Py
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 nobo
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' compa
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 dev
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 f
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
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"
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 platfo
1 - 100 of 283 matches
Mail list logo
