anatoly techtonik writes:
> I do not know what are you intending to do, but my opinion that
> fund raising for patching library is a waste of money.
Of course it's not a waste of money. The need is real, so as long as
the PSF and other organizations (GSoC) choose reasonable projects/
people to
l...@rmi.net writes:
> I agree that 3.X isn't all bad, and I very much hope it succeeds. And
> no, I have no answers; I'm just reporting the perception from downwind.
The fact is, though, that many of your "downwind" readers are not the
audience for Python 3, not yet. If you want to do Pytho
Simon de Vlieger writes:
> As for the potentially harmful text on Python 3 which is included on
> the python-commandments website I do get the hint that it might not be
> clear enough that the text does not apply to people who are porting
> libraries.
It also doesn't apply to people wh
Steven D'Aprano writes:
> Frankly, I believe that pushing the meme that "Python 3 is different" is
> a strategic mistake.
I agree that it's strategically undesirable. Unfortunately, the
genuine backward incompatibility, as well as the huge mind-share
already garnered by what I consider wrong-
get to 100% (or
a government-approved approximation of 100%). The topic on #python
seems unlikely to change at this point, with both Glyph and JP
pointedly failing to denounce it publicly, while Stephen defends it
and says it's not going to change as long as the libraries aren't
done.
What do y
Laurens Van Houtven writes:
> > The only situation in which I'd direct someone new to programming
> > away from Python 3 would be if they had a specific need to use a
> > library that wasn't yet supported.
>
> Yeah, I think the reason for that rule is that the majority of people
> asking abo
Laurens Van Houtven writes:
> Also, I'm pretty sure nobody has ever said that Python 3.x was a
> "failure", or anything like it. #python has claims that Python 3.x, as
> a platform for building production apps, is a work in progress
How about "Python 3 is a work in progress" for the topic? Th
h both Glyph and JP pointedly failing to
> denounce it publicly, while Stephen defends it and says it's not
> going to change as long as the libraries aren't done.
It would seem from posts I received after replying (local mail glitch,
should have know there was more coming :-( )
Guido van Rossum writes:
> On the #python issue, I expect that IRC is much less influential that
> some here fear (and than some fervent IRC users believe). I don't see
> reason for panic or heavy-handed interference. OTOH engaging the
> channel operators more in python-dev sounds like a usefu
Robert Collins writes:
> Also, url's are bytestrings - by definition;
Eh? RFC 3896 explicitly says
A URI is an identifier consisting of a sequence of characters
matching the syntax rule named in Section 3.
(where the phrase "sequence of characters" appears in all ancestors I
found ba
Lennart Regebro writes:
> 2010/6/21 Stephen J. Turnbull :
> > IMO, the UI is right. "Something" like the above "ought" to work.
>
> Right. That said, many times when you want to do urlparse etc they
> might be binary, and you might want binary. So mayb
P.J. Eby writes:
> Note too that this is an argument for symmetry in wrapping the
> inputs and outputs, so that the code doesn't have to "know" what
> it's dealing with!
and
> After all, right now, if a stdlib function might return bytes or
> unicode depending on runtime conditions, I can'
Barry Warsaw writes:
> Would it make sense to have "encoding-carrying" bytes and str
> types?
Why limit that to bytes and str? Why not have all objects carry their
serializer/deserializer around with them?
I think the answer is "no", though, because (1) it would constitute an
attractive nuisa
Ben Finney writes:
> "Stephen J. Turnbull" writes:
>
> > your base URL is gonna be b'mailto:step...@xemacs.org', but the
> > natural thing the UI will want to do is
> >
> > formurl = baseurl + '?subject=うるさいやつだなぁ…'
>
"Martin v. Löwis" writes:
> Still, the question would be whether any of these failures can manage to
> block a release.
Exactly. Personally, I would say that in a volunteer-maintained
project, "Platform X is supported" means that "There is a bug that
seems to affect only Platform X" is a cand
Barry Warsaw writes:
> I'm still not sure ebytes solves the problem,
I don't see how it can. If you have an encoding to stuff into ebytes,
you could just convert to Unicode and guarantee that all internal
string operations will succeed. If you use ebytes instead, every
string operation has to
Toshio Kuratomi writes:
> One comment here -- you can also have uri's that aren't decodable into their
> true textual meaning using a single encoding.
>
> Apache will happily serve out uris that have utf-8, shift-jis, and
> euc-jp components inside of their path but the textual
> representa
Robert Collins writes:
> Perhaps you mean 3986 ? :)
Thank you for the correction.
> > A URI is an identifier consisting of a sequence of characters
> > matching the syntax rule named in Section 3.
> >
> > (where the phrase "sequence of characters" appears in all ancestors I
> > foun
P.J. Eby writes:
> In Kagoshima, you'd use pass in an ebytes with your encoding to a
> stdlib API, and *get back an ebytes with the right encoding*,
> rather than an (incorrect and useless) unicode object which has
> lost data you need.
How does the stdlib do that? Unless it guesses which en
Michael Urman writes:
> It is somewhat troublesome that there doesn't appear to be an obvious
> built-in idempotent-when-possible function that gives back the
> provided bytes/str,
If you want something idempotent, it's already the case that
bytes(b'abc') => b'abc'. What might be desirable is
P.J. Eby writes:
> I know, it's a hard thing to wrap one's head around, since on the
> surface it sounds like unicode is the programmer's savior.
I don't need to wrap my head around it. It's been deeply embedded,
point first, and the nasty barbs ensure that I have no desire to pull
it back out
Glyph Lefkowitz writes:
> On Jun 21, 2010, at 10:58 PM, Stephen J. Turnbull wrote:
> > Note also that the "complete solution" argument cuts both ways. Eg, a
> > "complete" solution should implement UTS 39 "confusables detection"[1]
>
Toshio Kuratomi writes:
> I'll definitely buy that. Would urljoin(b_base, b_subdir) => bytes and
> urljoin(u_base, u_subdir) => unicode be acceptable though?
Probably.
But it doesn't matter what I say, since Guido has defined that as
"polymorphism" and approved it in principle.
> (I think
Nick Coghlan writes:
> On Tue, Jun 22, 2010 at 4:49 PM, Stephen J. Turnbull
> wrote:
> > > Which works if and only if your outputs are truly unicode-able.
> >
> > With PEP 383, they always are, as long as you allow Unicode to be
> > decoded to the same
Ian Bicking writes:
> Just for perspective, I don't know if I've ever wanted to deal with a URL
> like that.
Ditto, I do many times a day for Japanese media sites and Wikipedia.
> I know how it is supposed to work, and I know what a browser does
> with that, but so many tools will clean that
James Y Knight writes:
> The surrogateescape method is a nice workaround for this, but I can't
> help thinking that it might've been better to just treat stuff as
> possibly-invalid-but-probably-utf8 byte-strings from input, through
> processing, to output.
This is the world we already
Guido van Rossum writes:
> For example: how we can make the suite of functions used for URL
> processing more polymorphic, so that each developer can choose for
> herself how URLs need to be treated in her application.
While you have come down on the side of polymorphism (as opposed to
separat
Guido van Rossum writes:
> On Thu, Jun 24, 2010 at 1:12 AM, Stephen J. Turnbull
> wrote:
> Understood, but both the majority of str/bytes methods and several
> existing APIs (e.g. many in the os module, like os.listdir()) do it
> this way.
Understood.
> Also, IMO a po
ultimate target codec is 'euc-jp'-compatible.
Worse, you need to build in all the information about which codecs are
mutually compatible into the encoded-bytes type. For example, if the
ultimate target is known to be 'shift_jis', it's trivially compatible
with 'asci
Ian Bicking writes:
> We've setup a system where we think of text as natively unicode, with
> encodings to put that unicode into a byte form. This is certainly
> appropriate in a lot of cases. But there's a significant class of problems
> where bytes are the native structure. Network protoc
P.J. Eby writes:
> I do know the ultimate target codec -- that's the point.
>
> IOW, I want to be able to do to all my operations by passing
> target-encoded strings to polymorphic functions.
IOW, you *do* have text and (ignoring efficiency issues) could just as
well use str. But That Other
Ian Bicking writes:
> I'm proposing these specials would be used in polymorphic functions, like
> the functions in urllib.parse. I would not personally use them in my own
> code (unless of course I was writing my own polymorphic functions).
>
> This also makes it less important that the obj
Ian Bicking writes:
> I don't get what you are arguing against. Are you worried that if
> we make URL code polymorphic that this will mean some code will
> treat URLs as bytes, and that code will be incompatible with URLs
> as text? No one is arguing we remove text support from any of
> the
P.J. Eby writes:
> it's just that if you already have the bytes, and all you want to
> do is tag them (e.g. the WSGI headers case), the extra encoding
> step seems pointless.
Well, I'll have to concede that unless and until I get involved in the
WSGI development effort.
> >But with your arch
Greg Ewing writes:
> Would there be any sanity in having an option to compile
> Python with UTF-8 as the internal string representation?
Losing Py_UNICODE as mentioned by Stefan Behnel (IIRC) is just the
beginning of the pain.
If Emacs's experience is any guide, the cost in speed and complexit
P.J. Eby writes:
> At 12:42 PM 6/26/2010 +0900, Stephen J. Turnbull wrote:
> >What I'm saying here is that if bytes are the signal of validity, and
> >the stdlib functions preserve validity, then it's better to have the
> >stdlib functions object to unicode da
Steve Holden writes:
> I agree - trying to step through -O2 optimized code isn't going to
> help debug your code, it's going to help you debug the
> optimizer. That's a very rare use case.
Not really. I don't have a lot of practice in debugging at that
level, so take it with a grain of salt,
"Martin v. Löwis" writes:
> It seems that both Dirkjan and Brett are very caught up
> with real life for the coming months. So I suggest that
> some other committer who favors the Mercurial transition
> steps forward and takes over this project.
I am not a committer, and am not intimately fam
anatoly techtonik writes:
> After reading PEP 384 and PEP 385 (finally) I got a strong impression
> that they are not ready for the change (read below the line for
> details), because they do not propose any workflow.
This was deliberate. There are a lot of different workflows, and we
are not
anatoly techtonik writes:
> Why this transition is not described in PEP?
Please reread the whole thread, and the PEP.
PEP 385 is *incomplete* (see the red Warning at the top), and the
original proponent *is not going to have enough time to complete it
soon*. That being the case, Martin suggest
Steve Holden writes:
> If the wave were to result in good documentation about how to *get*
> ready that would be an amazingly useful contribution.
I'm a coauthor of PEP 374 and of http://emacswiki.org/BzrForEmacsDevs.
I think that I can have a document adapted from the Python dev FAQ,
possibly
Brett Cannon writes:
> Mercurial has subrepo support, but that doesn't justify the need to
> have every module in its own repository so they can be checked out
> individually.
The point of submodules a la git is subtly different. It is that you
can mix and match *known versions* of the module
Jesse Noller writes:
> On Sat, Jul 3, 2010 at 7:05 AM, Dirkjan Ochtman wrote:
> > On Sat, Jul 3, 2010 at 12:53, Stephen J. Turnbull
> > wrote:
> >> The point of submodules a la git is subtly different. It is that you
> >> can mix and match *known vers
Georg Brandl writes:
> I wouldn't say that. strip works well and it does so logically,
> once one understands the DAG. The only thing discouraged is to strip
> changesets once pushed to the public repo, but that holds as well for
> getting rid of the changesets by making a new clone without
Antoine Pitrou writes:
> Which is the very wrong thing to do, though. License text should be
> understandable by non-lawyer people;
This is a common mistake, at least with respect to common-law systems.
Licenses are written in a formal language intended to have precise
semantics, especially in
Steven D'Aprano writes:
> On Tue, 6 Jul 2010 01:58:26 pm Stephen J. Turnbull wrote:
> > Licenses are written in a formal language intended to have
> > precise semantics, especially in the event of a dispute going to
> > court. What you wrote is precisely analog
LD 'Gus' Landis writes:
> Yes. The BSD license on FreeBSD has allowed Apple to
> make MacOS X a completely proprietary product.
That's simply not true.
http://www.opensource.apple.com/release/mac-os-x-1064/.
___
Python-Dev mailing list
Python-Dev@pytho
Greg Ewing writes:
> The use cases I had in mind for a 1-byte build are those for
> which the alternative would be keeping everything in bytes.
> Applications using a 1-byte build would need to be aware of
> the fact and take care to slice strings at valid places. If
> they were using bytes,
Antoine Pitrou writes:
> > http://selenic.com/hg/file/tip/mercurial/minirst.py
>
> Given that Mercurial is GPL, this is probably of no use to us,
> unfortunately.
Given that Martin apparently is the only or main author, I don't see a
problem as long as he's willing.
Martin?
__
Benjamin Peterson writes:
> 2010/7/7 Stephen J. Turnbull :
> > Antoine Pitrou writes:
> >
> > > > http://selenic.com/hg/file/tip/mercurial/minirst.py
> > >
> > > Given that Mercurial is GPL, this is probably of no use to us,
> > >
Steve Holden writes:
> That is _so_ Python 2 ;-)
High praise!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.co
Antoine Pitrou writes:
> You don't have to receive e-mail from it. Just take a look at the
> archives from time to time after you have done some commits.
> In a threaded view, it's easy to spot the few messages which aren't
> commit notifications, since they are the only one not at the
> top-
Guilherme Polo writes:
> Adding tabs doesn't necessarily mean a single window, you should be
> able to continue using multiple windows with single tabs if that is
> your preference.
But it's very important to be able to *move* tabs across windows or
panes. For example, in XEmacs this is a som
Mark Lawrence writes:
> Is this the same login as for the issue tracker or is a new one needed?
It's different. Both trackers are supposed to support OpenID logins,
I believe. (However, there are somewhat frequent reports of
difficulties with it; I don't know if the system is fully debugged.
R. David Murray writes:
> During the most recent discussion I can remember, I thought I remembered
> Stephen Trumble saying that they'd tried that in xemacs and it really
> hadn't worked very well. Since he now says he thinks it's a good idea
> (or more likely I
Oleg Broytman writes:
> > Back on the topic, I don't think a drop-down list of all modules is
> > workable even in browsers that display them as combo boxes. How many
> > modules do we have in std lib? About 100? Maybe more. What if the
> > bug affects several modules? What if the patch mo
Alexander Belopolsky writes:
> On Wed, Jul 21, 2010 at 2:09 AM, Stephen J. Turnbull
> wrote:
> ..
> > > In this particular case I'd rather tend to agree - an editable
> > > single-line box to enter space-*and*-comma-separated modules list
&g
Greg Ewing writes:
> Scott McCarty wrote:
> > All, I have searched everywhere (mostly the code and a little google)
> > and I cannot understand where the SIGKILL signal gets checked when it is
> > set as a handler.
>
> Possibly it's not being checked at all by Python, but
> is being rejec
Greg Ewing writes:
> Glyph Lefkowitz wrote:
>
> > The selection of RuntimeError in this particular case seems
> > somewhat random and ad-hoc,
Well, I guess we'd have to catch the person who wrote the code and
ask.
> Maybe this is something that could be considered in the
> exception hierar
Oleg Broytman writes:
> On Wed, Jul 21, 2010 at 07:28:24PM -0600, average wrote:
> > As to your question of how best to handle inquiries from the blue or
> > "noisy questions", I personally prefer the following (only slightly
> > tongue-in-cheek):
> >
> > ...After a sufficient period of wait
anatoly techtonik writes:
> Don't you think it is a bad idea to require people to subscribe to
> post to python-ideas of redirected there?
No, it's an excellent compromise in the current environment. On lists
I manage (with a similar audience to python-dev), my MTA-level filters
get 95% of the
Georg Brandl writes:
> Am 26.07.2010 10:59, schrieb Anders Sandvig:
> > On Sat, Jul 24, 2010 at 3:31 AM, Gregory P. Smith wrote:
> >> Yuck. Anyone who feels they need a variable named the same a reserved
> >> word
> >> simply feels wrong and needs reeducation. [...]
> >
> > While I agre
Steve Holden writes:
> > Only if they have similar look and feel, and don't require you to
> > register the same login N times, though.
> >
> Is it really time to give devs a distributed identity good for a range
> of systems? Sounds like a potentially hairy management task.
Sure, but Pytho
Hrvoje Niksic writes:
> single "branch", not an entire tree. I'd imagine a mktree function to
> accept a data structure describing the tree to be created.
-1 on mktree for that reason.
> If you're going for a short name distinctive from mkdir, I propose
> mksubdirs.
A little more accurat
Ron Adam writes:
> Something that may be more useful, is a "no activity" search field
> with choices of day, week, month, year, etc... and make the output
> sortable on time without activity.
That's exactly what a sort on date of activity gives you, though, and
it can be from longest down.
Al
Ron Adam writes:
> Yes, but when I do it, I either get a single specific day, or 2700
> issues.
If your query specifies an activity date, you will get only issues
with activity that date. If it sorts or groups on activity date, you
will get all issues (subject to other conditions), but you can
Mark Lawrence writes:
> I completely disagree.
Mark, please stop being disagreeable. The above is *not true*.
You've made no statements I can recall insisting that the only way to
skin a cat is to use a GNOME theme, only that the cat needs skinning.
Before you posted that, Benjamin had already
Steven D'Aprano writes:
> I don't know. What percentage of new issues get ever get a response? My
> wild guess is that it's probably about 99.9%, but the 0.1% that don't
> remain languishing forever, skewing the statistics.
No guess needed, we have the data. If the fraction "a" of issues ev
Steve Holden writes:
> No, you don't, and the current discussion about how to ensure that bug
> reporters get at least the courtesy of a relatively quick reply is one
> of the most promising developments in building a welcoming community
> that I can remember.
C'mon Steve, it's not hard to se
Steve, thanks for your care-full reply.
Steve Holden writes:
> Particularly when the issue tracker works ...
Well, sometimes it's down.But Roundup is more flexible as
a database engine than a lot of people realize. Better docs would
help, I'm sure, but we can also create new standard queri
Greg Ewing writes:
> I'm not aware of any system that's "just like Windows"
> except that it uses something other than colons.
It's a shame that Windows machines can be networked; otherwise we
could formally treat drive letters as the scheme component of file
URLs.
Steve Holden writes:
> But I see rules being established ("there's a language moratorium: no
> changes!", "no release should be made unless the buildbots are *all*
> green") and then ignored apparently on a whim. This doesn't give people
> any confidence that the rules actually mean much, and
Benjamin Peterson writes:
> 2010/8/9 Nick Coghlan :
> > On Tue, Aug 10, 2010 at 2:10 AM, alexander.belopolsky
> > wrote:
> >> +PS: In the standard Python distribution, this file is encoded
> >> in UTF-8 +and the list is in rough alphabetical order by last
> >> names.
> >>
> >> David Abrah
Michael Foord writes:
> > I think the point is that *because* people don't want to change
> > their ideas, it would be good to have a mingw-based alternative.
> > Otherwise everyone is forced to convert to the Windows religion.
> You mean people using Windows are forced to use Windows?
By fa
Michael Foord writes:
> How is ~/python not memorable or consistent? (And cross-platform
> memorability and consistency is valuable too.)
But what does "~" mean on Windows? Inside of Python you can have a
consistent definition, but that doesn't help people whose installer
gets mixed signals so
Tarek Ziadé writes:
> "Good enough metadata" sounds completely wrong to me.
I hate to break it to you, but experience shows that the XEmacs
package system, whose dependency tracking is in theory a pile of
braindamaged rubbish, an abomination in the sight of She Who Created
The World With 4-Space
Nick Coghlan writes:
> (Basically, while the issue of programmers assuming 'latin-1' or
> 'utf-8' or similar ASCII friendly encodings when they shouldn't is
> real, I don't believe a polymorphic API here will make things any
> *worse* than what would happen with a parallel API)
That depends o
Neil Hodgson writes:
>Over time, the set of trail bytes used has expanded - in GB18030
> digits are possible although many of the most important characters
> for parsing such as ''' "#%&.?/''' are still safe as they may not
> be trail bytes in the common double-byte character sets.
That's
Guido van Rossum writes:
> I would recommend that in the future more attention is paid to
> "documenting" publicly that someone's being booted out was
> inevitable, by an exchange of messages on python-dev (or
> python-committers if we want to limit distribution). And no, I
> don't think tha
Cameron Simpson writes:
> I've just read that thread. Mark doesn't sound that way to me. "I
> disagree entirely" is an entirely valid response, when backed up
> with argument, such as his immediately following sentence:
>
> Perhaps we should simply agree to disagree,
Agreeing to disagree
Georg Brandl writes:
> You should read my tweets more often :)
Now *there* is an innovation that never should have happened!
At least you're bringing up the average quality with every twit I mean
tweet.
___
Python-Dev mailing list
Python-Dev@python.o
"Martin v. Löwis" writes:
> I didn't say the field does not matter. I said adjusting it doesn't
> advance the issue. Anybody *really* working on the issue might
> choose to update it, or might choose to leave it incorrect when the
> issue is going to be closed, anyway.
Yes, and we'd all like
Éric Araujo writes:
> How about revamping the type/versions fields?
>
> Issue type () Feature request (blocked by moratorium: () yes () no)
I think the information about "blocked by moratorium" is not something
that users or devs will care about much. The users can be informed
about the fact
Paul Moore writes:
> In fact, with userfs, I believe it's possible to do massively
> pathological things like having a filesystem which treats anagrams
> as the same file (foo is the same file as oof or ofo). (More
> realistically, MacOS does Unicode normalisation).
Nitpick: Mac OS X doesn't
Éric Araujo writes:
> Le 25/09/2010 10:20, anatoly techtonik a écrit :
> > Python ML are:
> > 1. require dedicated admin to update, who is not a member of the group
> > 2. don't have search
> > 3. don't have optional thread subscription
> > That's already enough to seek better platform for c
Barry Warsaw writes:
> You can have "co-located" branches[1] which essentially switch
> in-place, so if a branch is changing some .c files, you won't have
> to rebuild the whole world just to try out a patch.
In Mercurial these are called "named branches", and they are
repo-local (by which I m
Sorry for following up to myself, but this typo might be very
confusing:
Stephen J. Turnbull writes:
> Barry Warsaw writes:
>
> > You can have "co-located" branches[1] which essentially switch
> > in-place, so if a branch is changing some .c files, you won'
Barry Warsaw writes:
> I should note that I don't particularly like colocated/named branches. I
> personally much prefer separate directories for each feature or bug I'm
> working on. It helps me keep track of what I'm doing. I have a fast machine
> so recompiling all of Python is no big de
R. David Murray writes:
> On Mon, 04 Oct 2010 12:32:26 -0400, Scott Dial
> wrote:
> > On 10/2/2010 7:00 PM, R. David Murray wrote:
> > > The clever hack (thanks ultimately to Martin) is to accept 8bit data
> > > by encoding it using the ASCII codec and the surrogateescape error
> > > handle
Nick Coghlan writes:
> - if you pass in bytes data and know what you are doing, then you can
> access that raw bytes data and do your own decoding
At what level, though?
To take an interesting example I used to see frequently:
From: t...@tokyo.jp
(Taro Yamada in 8-bit Shift JIS)
So I g
R. David Murray writes:
> version of headers to the email5 API, but since any such data would
> be non-RFC compliant anyway, [access to non-conforming headers by
> reparsing the bytes] will just have to be good enough for now.
But that's potentially unpleasant for, say, Mailman. AFAICS, what
R. David Murray writes:
> 5. Return the content, with non-ASCII bytes replaced with ?
> characters.
That hadn't occurred to me (and it makes me sick to contemplate it).
That said, this is probably good enough for Mailman-like apps to limp
along for "most" users. It's certainly good enoug
R. David Murray writes:
> So the only parsing issue is if Mailman cares about *the non-ASCII
> bytes* in the headers it cares about. If it has to modify headers that
> contain non-ASCII bytes (for example, addresses and Subject) and cares
> about preserving the non-ASCII bytes, then there is
R. David Murray writes:
> > The MIME-charset = UNKNOWN dodge might be a better way of handling
> > this.
>
> That is a very interesting idea. It is the *right* thing to do, since it
> would mean that a message parsed as bytes could be generated via Generator
> and passed to, say, smtplib w
l...@rmi.net writes:
> To put that more strongly, the Python user base is much larger than
> this list's readership.
Agreed. Nevertheless, this is the channel (not "channel") that the
developers listen on, and substantial effort is made to let Python
users know that. I think they do know it,
Barry Warsaw writes:
> Header wrapping sucks even more because it's supposed to take the
> semantic context into account, which means that a generic Header
> wrapping algorithm cannot work for everything. E.g. Received:
> headers are supposed to wrap after the semicolon.
Received headers are
Barry Warsaw writes:
> On Oct 07, 2010, at 04:40 AM, Stephen J. Turnbull wrote:
> I'm fairly certain that most of the modern causes of [Unicode
> errors in Mailman] are post-parse modifications of the message.
> IOW, in Mailman's architecture, we try to parse the raw
R. David Murray writes:
> On Sat, 09 Oct 2010 01:06:29 +0900, "Stephen J. Turnbull"
> wrote:
> > That mess is entirely unnecessary in Python 3. Text and wire format
> > can be easily distinguished with three different representations of
> > email: Unicod
Barry Warsaw writes:
> On Oct 09, 2010, at 02:48 AM, Stephen J. Turnbull wrote:
>
> >Right. That's where I was going with my comment to Barry about the
> >Received headers. Even if email isn't going to serve clients working
> >with wire format, it need
Steven D'Aprano writes:
> I don't think anyone has ever suggested change for change's sake. If
> they have, I'd love to read the PEP for it.
Not to mention the BDFL's pronouncement message!
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
901 - 1000 of 1553 matches
Mail list logo
