Hello,
THE PROBLEM:
I am having a problem that I have seen asked quite a bit on the web, with
little to no follow up.
The problem is essentially this. When embedding (LoadLibraryA()) the python
interpreter dll
in a non-windows application the developer must first create a console for
python to d
Josiah Carlson writes:
> fine). While I have heard comments along the lines of "the docs could
> be better", I've never heard the claim that the Python docs are "lousy".
FYI, I have heard this, recently, from Tom Lord (aka developer of
Arch, rx, guile, etc). Since he also took a swipe at Emac
xah lee writes:
> anyway, i've rewrote the Python's RE module documentation, at:
> http://xahlee.org/perl-python/python_re-write/lib/module-re.html
-1
The current docs could be improved (but not by me, at least not
today), but I don't consider the general direction of Xah's edits
desirable.
Talin writes:
> (one additional postscript - One thing I would be interested in is an
> approach that unifies file paths and URLs so that there is a consistent
> locator scheme for any resource, whether they be in a filesystem, on a
> web server, or stored in a zip file.)
+1
But doesn't fi
Scott Dial writes:
> [EMAIL PROTECTED] wrote:
> > Talin writes:
> > > (one additional postscript - One thing I would be interested in is an
> > > approach that unifies file paths and URLs so that there is a consistent
> > > locator scheme for any resource, whether they be in a filesystem,
Michael Urman writes:
> Ah, but how do you know when that's wrong? At least under ftp:// your
> root is often a mid-level directory until you change up out of it.
> http:// will tend to treat the targets as roots, but I don't know that
> there's any requirement for a /.. to be meaningless (eve
On Mon, Aug 4, 2014 at 12:12 AM, Larry Hastings wrote:
>
> Several people have said they found the name "nullable" surprising,
> suggesting I use another name like "allow_none" or "noneable". I, in turn,
> find their surprise surprising; "nullable" is a term long associated with
> exactly this c
h familiarity. It's also deeply subjective.
But its an objective reality, imho, that having to maintain and sync up
function definitions in *two different files* is a burden. And that is a
burden I really don't want to deal with.
--Stephen
___
t www.open-std.org/JTC1/sc22/wg23.
Thank you.
Stephen Michell
Maurya Software
stephen dot michell at maurya dot on dot ca
Phone: 1-613-299-9047___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscri
stephen.mich...@maurya.on.ca
<mailto:stephen.mich...@maurya.on.ca> to respond directly.
Thank you
…stephen michell
Convenor
ISO/IEC/JTC 1/SC 22/WG 23 Programming Language Vulnerabilities Working Group___
Python-Dev mailing list
Python-Dev@python.org
e this would break is astronomical.
--
Stephen Hansen
m e @ i x o k a i . i o
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
to do basically anything, INCLUDING produce
closed source releases if someone wanted to, or just release
modifications or modules that are available under different licenses.
The OSD encompasses both ends of the spectrum: the GPL's mandate of
source access and the OSD's mandate of t
that happen to be 7-bit ascii-compatible and can't perform text-ish
operations on them--
Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more informa
this is not a problem, just a burning desire for
closure (even if anecdotal) as to how this can be. I deeply love python,
and am not complaining! I stumbled across this and found it truly
confounding, and thought the gurus here may happen to recall what changed
in 3.x that lead the the error cond
.
f.write("foo_2()\n\n")
foo_2() will succeed in python 2.x because the CALL_FUNCTION is not
explicitly getting more than 255 parameters. Very interesting!
Thank you both again for your responses, I am grateful to finally
understand the way in which success / failure works h
omers;
I love Python and am an advocate for it, but in my day job, pushing things
forward is just about at the bottom of my list of concerns. (Though, our
migration to 2.7 is actually part of a long term strategic plan to embrace
pypy)
And now I go back to lurking.
--Stephen
___
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.com
utils related issues,
If you could look at a solution for http://bugs.python.org/issue1533164
I would be eternally grateful.
--
Regards,
Stephen Thorne
Development Engineer
NetBox Blue - 1300 737 060
NetBox Blue is proud to be a sponsor and exhibitor at IBM's Solutions
Showcase 2009 events
want to be able to access the files they
tell me they want.
For anyone who is doing something low-level, they can use the bytes API.
--Stephen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
ic decision-making process would be appropriate).
Yes, #python keeps the text "It's too early to use Python 3.x" in its topic.
Library support is the only reason.
--
Regards,
Stephen Thorne
Development Engineer
___
Python-Dev mailing list
vent to your discussion about python 3 ports.
--
Regards,
Stephen Thorne
___
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.com
P are great examples, but there is plenty of room for all
> sorts of initiatives that result in development opportunities. I'd like
> to help.
I am extremely keen for this to happen. Does anyone have ownership of this
project? There was some discussion of it up-lis
On 2010-06-25, "Martin v. Löwis" wrote:
> Am 25.06.2010 01:28, schrieb Stephen Thorne:
> > Steve Holden Wrote:
> >> Given the amount of interest this thread has generated I can't help
> >> wondering why it isn't more prominent in python.org cont
On 2010-06-25, "Martin v. Löwis" wrote:
> > What page were we suggesting linking to?
>
> I don't think anybody proposed anything specific. Steve Holden
> suggested it should go to "reasoned discussion of the
> pros and cons as evinced in this thread"
many excellent full-featured Python IDE's out there after they advance
to that point) then not.
--Stephen
___
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.com
On Sun, Jul 11, 2010 at 4:53 PM, Steve Holden wrote:
> Stephen Hansen wrote:
> > On Sat, Jul 10, 2010 at 9:23 PM, Guilherme Polo > <mailto:ggp...@gmail.com>> wrote:
> >
> > By "never had a problem" do you mean using some of the latest
> vers
y. Is it all
pull/poll oriented, or does the slave need to be connected to by the master?
Meaning, do I need to poke a hole in the firewall to allow any external
access? The BuildBot page only mentions outgoing access (or I'm
misunderstanding it).
IIUC, I just need a name
On Fri, Oct 8, 2010 at 2:42 AM, Antoine Pitrou wrote:
> On Tue, 5 Oct 2010 10:08:59 -0700
> Stephen Hansen wrote:
> > On Sat, Oct 2, 2010 at 1:37 PM, "Martin v. Löwis" >wrote:
> >
> > > > I'm already running a Jython buildslave on an Intel Ma
On Fri, Oct 8, 2010 at 8:00 AM, Antoine Pitrou wrote:
>
> Hi,
>
> > The failure is happening just because it can't possibly succeed, I set
> > up the account for the buildbot in such a way that it has no access to
> > a GUI context. I'm going to rectify that today so I can properly test
> > TK.
>
en the buildbot is, and I can't see what.
--Stephen
___
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.com
On Fri, Oct 8, 2010 at 10:28 AM, Antoine Pitrou wrote:
> On Fri, 8 Oct 2010 10:02:59 -0700
> Stephen Hansen > wrote:
> >
> > And long story short, it gets to 201 and runs test_cmd_line in the same
> > order as the buildbot did, and it succeeds too, and I curse the go
On Fri, Oct 8, 2010 at 11:09 AM, Stephen Hansen
> wrote:
> On Fri, Oct 8, 2010 at 10:28 AM, Antoine Pitrou wrote:
>
>> On Fri, 8 Oct 2010 10:02:59 -0700
>> Stephen Hansen > wrote:
>> >
>> > And long story short, it gets to 201 and runs test_cmd_line
ildslave on. Despite being a VM
it gets ownership of two cores and 4 gigs of RAM, so should be plenty
fast to handle the load. And I do run it 24/7.
--
Stephen Hansen
... Also: Ixokai
... Mail: me+python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/
signature.asc
Description: Open
On 10/13/10 3:14 PM, "Martin v. Löwis" wrote:
> Am 14.10.2010 00:08, schrieb Stephen Hansen:
>> On 10/13/10 2:47 PM, Antoine Pitrou wrote:
>>> (you'll notice that we have currently no 64-bit Windows machine although
>>> 64-bit support under Windows has
e, but this again
> is more complicated).
Oh! Well if it takes a paid version of VS, then I won't be able to do
it. I'll experiment with getting the SDK and using that and seeing if I
can make it work.
--
Stephen Hansen
... Also: Ixokai
... Mail: me+python (AT) ixokai (D
he whole visual studio environment set up.
I have computing resources, cycles, and time that's free to offer up:
but the differing responses here makes me unsure if I'm being useful or
not in trying here :)
--
Stephen Hansen
... Also: Ixokai
... Mail: me+python (
comfortable opening up such access except on a
person-by-person/case-by-case basis.
I idle on #python-dev as "ixokai" -- you can ping me there and I
generally wake up rather promptly. That, or email works too.
--
Stephen Hansen
... Also: Ixokai
... Mail: me+python
odespeak.net/issue/pypy-dev/issue240
Is there a good reason for this behaviour? It has broken my code (a
subclass of dict that populates a key before calling the superclasses
constructer, in the twisted codebase).
--
Stephen Thorne
"Give me enough b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Re: the discussion in:
http://mail.python.org/pipermail/python-dev/2006-March/062823.html
Just as an FYI, the tlslite package (http://trevp.net/tlslite/) got
broken in Python 2.5 and needed the exact fix quoted in the URL above.
It was an easy fix,
I'm a long-term lurker and Python coder, and although I've never really
contributed much to the list, I do make a point to keep up on it so I'm
prepared at least when changes come through. This thread's gone on forever,
so I thought I'd offer my opinion :) Mwha.
Ahem.
First of all, I think the c
For example, I committed a fix for urllib that made it raise IOError
instead
of an AttributeError (which wasn't explicitly raised, of course) if a
certain
error condition occurs.
This is changed behavior too, but if we are to postpone all these fixes
to 3.0, we won't have half of the fixes in Pyt
be my second contribution ever. And the first one to be more
then a line and a half :P
--
Stephen Hansen
Development
Advanced Prepress Technology
[EMAIL PROTECTED]
(818) 748-9282
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
That may actually be a genuinely useful approach:
splitext(name, ignore_leading_dot=False, all_ext=False)
... that's perfect. I updated my patch to do it that way! :)
--S
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
I'm sure everyone remembers the big ol' honking discussion on the change to
os.splitext; it sorta fizzled after Guido asked if people would accept a
pronouncement on the subject. I'm not anyone in the Python world, but felt
strongly enough on the particular subject to submit a patch (and later
rev
Anthony Baxter said that the patch wasn't making it into 2.5.1, and
since he is the release manager, his word is just about as final as
Guido's (at least regarding the releases he does).
Ah, oops! Work got busy, and I must have missed that in the Endless Threads.
Nevermind then. :)
--S
__
') isn't supported on Windows XP, I'll be very sad, and will have
to be stuck on Python 3.x-1 for .. awhile, where "awhile" is out of my
control and up to the Masses who are unable or can't be bothered with
fixing what works for them w/ WinXP.
--
Stephen Hansen
e? Please help me on that, thanks
you.
--
If you have any other question about your web portal please contact me. At
N-Pinokyo we value our customers and will be more than happy to assist you
with any other matter related to our service.
Regards,
Stephen Yeng
__
on about your web portal please contact me. At
N-Pinokyo we value our customers and will be more than happy to assist you
with any other matter related to our service.
Regards,
Stephen Yeng
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
The kind of errors I mentioned ("permission denied" errors that
seem to occur without an obvious reason) have cost me at least
two weeks of debugging the hard way (with ProcessExplorer etc)
and caused my manager to loose his trust in Python at all...
I think it is well worth the effort to keep th
thin are available
everywhere. 'root' speaks to me too much of trees, and while namespaces may
be tree-like, __root__ alone doesn't say "root namespace"... and
__root_namespace__ is long.
(Then again, long for a feature that should only be used with care isn&#x
gt; import this
Is distutils being over-cautious in flattening out all whitespace? A
w3c discussion on multiple lines in rfc822 [1] seems to suggest that
whitespace can be 'unfolded' safely, so it seems a shame to be
throwing it away when it can have important mean
I have created issue #1923 to keep track of this.
Stephen Emslie
On Jan 23, 2008 6:00 PM, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> could you put this on bugs.python.org and follow up with a reference to the
> issue # for better tracking?
>
>
>
> On 1/23/08, stephen
Phillip J. Eby wrote:
> ... if tools exist and are distributed for such a [PEP 262] "database",
> and *everybody* agrees to use it as an officially-blessed standard,
> then it should be possible for setuptools to co-exist with that
> framework, and we're all happy campers.
I like this idea and
PJE's idea here is very good. Just include certain files and such in
the RPM/DEB that will satisfy the "python-package-management" system. For
RPM/DEB users and their OS's database of packages, its irrelevant largely--
they'll still keep u
*sorted* dictionary-- sorting on insertion time. I'd expect
a sorted dictionary to shift itself around as appropriate. I'd not expect an
ordered dictionary to change the order without some explicit action.
To me, "ordered dictionary" is in fact a *preordered* dictionary. The
nary package into python/tcl
(i.e. python/tcl/tile0.5) with all the other tcl packages, but tcl
can't find it. Any ideas?
Traceback (most recent call last):
File "Script1.py", line 5, in ?
root.tk.call('package', 'require', 'tile')
_tkinter
On Wed, 19 Jan 2005 19:03:25 -0500, Timothy Fitz <[EMAIL PROTECTED]> wrote:
> On Thu, 20 Jan 2005 09:03:30 +1000, Stephen Thorne
> <[EMAIL PROTECTED]> wrote:
> > "Flat is better than nested" has one foot in concise powerful
> > programming, the other foot
(PyExc_TypeError,
"sequence expected, %.80s found",
orig->ob_type->tp_name);
return NULL;
}
I can't see an obvious solution, but perhaps generators should get
special treatment rega
rced to
"hide" it by putting it on a non-standard port. Very weak.
I am no networking expert so the suggestions for using a reverse
proxy are very welcome and I will look into that right away. Just
wanted to add my voice to the security concerns.
stephen
__
Andreas Maier writes:
> The problem of the default implementation is that "x is not y"
> implies "x != y" and that may or may not be true under a sensible
> definition of equality.
I noticed this a long time ago and just decided it was covered by
"consenting adults". That is, if the "sensible
Andreas Maier writes:
> A class designer can directly implement what equality means to the
> class, but he or she cannot implement an accessor method for the
> value.
Of course she can! What you mean to say, I think, is that Python does
not insist on an accessor method for the value. Ie, the
Ethan Furman writes:
> And what would be this 'sensible definition' [of value equality]?
I think that's the wrong question. I suppose Andreas's point is that
when the programmer doesn't provide a definition, there is no such
thing as a "sensible definition" to default to. I disagree, but given
Rob Cliffe writes:
> > Why? What value (pun intended) is there in adding an explicit statement
> > of value to every single class?
> It troubles me a bit that "value" seems to be a fuzzy concept - it has
> an obvious meaning for some types (int, float, list etc.) but for
> callable objects
Chris Angelico writes:
> The reason NaN isn't equal to itself is because there are X bit
> patterns representing NaN, but an infinite number of possible
> non-numbers that could result from a calculation.
I understand that. But you're missing at least two alternatives that
involve raising on
Steven D'Aprano writes:
> I don't think so. Floating point == represents *numeric* equality,
There is no such thing as floating point == in Python. You can apply
== to two floating point numbers, but == (at the language level)
handles any two numbers, as well as pairs of things that aren't
numb
Alexander Belopolsky writes:
> Why have builtin sum at all if its use comes with so many caveats?
Because we already have it. If the caveats had been known when it was
introduced, maybe it wouldn't have been. The question is whether you
can convince python-dev that it's worth changing the defi
Alexander Belopolsky writes:
> On Sat, Aug 9, 2014 at 3:08 AM, Stephen J. Turnbull
> wrote:
>
> > All the suggestions
> > I've seen so far are (IMHO, YMMV) just as ugly as the present
> > situation.
> >
>
> What is ugly about allowing strings
Chris Angelico writes:
> The justification is illogical. However, I personally believe
> boilerplate should be omitted where possible;
But it mostly can't be omitted. I wrote 22 classes (all trivial)
yesterday for a Python 3 program. Not one derived directly from
object. That's a bit unusual
Glenn Linderman writes:
> On 8/10/2014 1:24 AM, Stephen J. Turnbull wrote:
> > Actually ... if I were a fan of the "".join() idiom, I'd seriously
> > propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could
> > deprecate "".join(strin
Chris Barker - NOAA Federal writes:
> Is there anything in the language spec that says string concatenation is
> O(n^2)? Or for that matter any of the performs characteristics of build in
> types? Those striker as implementation details that SHOULD be particular to
> the implementation.
Conta
Ethan Furman writes:
> On 08/11/2014 08:50 PM, Stephen J. Turnbull wrote:
> > Chris Barker - NOAA Federal writes:
> >
> >> It seems pretty pedantic to say: we could make this work well,
> >> but we'd rather chide you for not knowing the "proper"
Redirecting to python-ideas, so trimming less than I might.
Chris Barker writes:
> On Mon, Aug 11, 2014 at 11:07 PM, Stephen J. Turnbull
> wrote:
>
> > I'm referring to removing the unnecessary information that there's a
> > better way to do it, and simply
Ben Hoyt writes:
> Fair enough. I don't quite understand, though -- why is the "official
> policy" to kill something that's "essential" on *nix?
They're not essential on *nix. Unix paths at the OS level are "just
bytes" (even on Mac, although the most common Mac filesystem does
enforce UTF-8 U
Greg Ewing writes:
> Stephen J. Turnbull wrote:
>
> > This case can be handled now using the surrogateescape
> > error handler,
>
> So maybe the way to make bytes paths go away is to always
> use surrogateescape for paths on unix?
Backward compatibility
Guido van Rossum writes:
> On Tuesday, August 19, 2014, Stephen J. Turnbull wrote:
> > Greg Ewing writes:
> > > So maybe the way to make bytes paths go away is to always
> > > use surrogateescape for paths on unix?
> >
> > Backward compatibilit
Marko Rauhamaa writes:
> Unix programmers, though, shouldn't be shielded from bytes.
Nobody's trying to do that. But Python users should be shielded from
Unix programmers.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailm
Nick Coghlan writes:
> One idea I had along those lines is a surrogatereplace error handler (
> http://bugs.python.org/issue22016) that emitted an ASCII question mark for
> each smuggled byte, rather than propagating the encoding problem.
Please, don't.
"Smuggled bytes" are not independent ev
Marko Rauhamaa writes:
> My point is that the poor programmer cannot ignore the possibility of
> "funny" character sets.
*Poor* programmers do it all the time. That's why Python codecs raise
when they encounter bytes they can't handle.
> If Python tried to protect the programmer from that po
Chris Barker - NOAA Federal writes:
> This brings up the other key problem. If file names are (almost)
> arbitrary bytes, how do you write one to/read one from a text file
> with a particular encoding? ( or for that matter display it on a
> terminal)
"Very carefully."
But this is strictly fr
Chris Barker writes:
> > The third is to specify the UTF-8 with the surrogate escape error
> > handler. This allows non-UTF-8 codes to be loaded into
> > memory.
Read as bytes and incrementally decode. If you hit an Exception,
retry from that point.
> Just so I'm clear here -- if you write
Chris Angelico writes:
> Not sure why 1251,
All of those codes have repertoires that are Cyrillic supersets,
presumably Russian-language content, based on Oleg's top domain.
> But it's important to note that this is a method of handling junk.
> It's not a design intention; this is for a situa
Chris Barker writes:
> So I write bytes that are encoded one way into a text file that's encoded
> another way, and expect to be abel to read that later?
No, not you. Crap software does that. Your MUD server. Oleg's
favorite web pages with ads, or more likely the ad servers.
> Not for me (
Oleg Broytman writes:
>This is the core of the problem. Python2 favors Unix model but
> Windows people pays the price. Python3 reverses that
This is certainly not true. What is true is that Python 3 makes no
attempt to make it easy to write crappy software in the old Unix
style, that break
Nick Coghlan writes:
> "purge_surrogate_escapes" was the other term that occurred to me.
"purge" suggests removal, not replacement. That may be useful too.
neutralize_surrogate_escapes(s, remove=False, replacement='\uFFFD')
maybe? (Of course the remove argument is feature creep, so I'm only
R. David Murray writes:
> Also, as has been discussed in this thread previously, any program that
> deals with filenames is dealing with human readable languages, even
> if posix itself treats the filenames as bytes.
That's a bit extreme. I can name two interesting applications
offhand: git's
Isaac Morland writes:
> I like your way of putting this - "straight face" indeed. The third
> option really is a hack to allow working around nonsensical situations
> (and even the META tag is pretty questionable). All this complexity
> because people can't be bothered to do things proper
Nikolaus Rath writes:
> In that case, maybe it'd be nice to also explain why you use the
> term "bilingual" for codepage based encoding.
Modern computing systems are written in languages which are invariably
based on syntax expressed using ASCII, and provide by default
functionality for express
Glenn Linderman writes:
> On 8/26/2014 4:31 AM, MRAB wrote:
> > On 2014-08-26 03:11, Stephen J. Turnbull wrote:
> >> Nick Coghlan writes:
> > How about:
> >
> > replace_surrogate_escapes(s, replacement='\uFFFD')
> >
> >
Glenn Linderman writes:
> On 8/27/2014 5:16 AM, Nick Coghlan wrote:
> > Choosing UTF-8 aims to treat formatting text for communication with
> > the user as "just a display issue". It's a low impact design that will
> > "just work" for a lot of software, but it comes at a price:
> >
> > *
Glenn Linderman writes:
> On 8/27/2014 6:08 PM, Stephen J. Turnbull wrote:
> > Glenn Linderman writes:
> > > And further, replacement could be a vector of 128 characters, to do
> > > immediate transcoding,
> >
> > Using what encoding?
>
Nick Coghlan writes:
> The current proposal on the issue tracker is to instead take advantage of
> the existing error handlers:
>
> def convert_surrogateescape(data, errors='replace'):
> return data.encode('utf-8', 'surrogateescape').decode('utf-8',
> errors)
>
> That code i
In the process of booking up for my other post in this thread, I
noticed the 'surrogatepass' handler.
Is there a real use case for the 'surrogatepass' error handler? It
seems like a horrible break in the abstraction. IMHO, if there's a
need, the application should handle this. Python shouldn't
Greg Ewing writes:
> M.-A. Lemburg wrote:
> > we needed
> > a way to make sure that Python 3 also optionally supports working
> > with lone surrogates in such UTF-8 streams (nowadays called CESU-8:
> > http://en.wikipedia.org/wiki/CESU-8).
Besides what Greg says, CESU-8 is an UTF, and therefo
mar...@v.loewis.de writes:
> BTW, it's patented:
>
> http://www.google.de/patents/US6816900
Damn them. I hope they never get a look at my crontab.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-d
Antoine Pitrou writes:
> On Tue, 2 Sep 2014 16:47:35 -0700
> Glyph Lefkowitz wrote:
> > As we keep saying, this is not a break in backwards
> > compatibility, it's a bug fix.
>
> Keeping saying it doesn't make it magically true.
It's not "magically" true, it is "just" true. What the hard
Nick Coghlan writes:
> Sorry, I haven't been a very good maintainer for that buildbot (the main
> reason it never graduated to the "stable" list). If you send me your public
> SSH key, I can add it (I think - if not, I can ask Luke to do it).
> Alternatively, CentOS 6 may exhibit the same prob
Guido van Rossum writes:
> lot: five years ago (when I worked at Google!) it was common to find
> internal services that required SSL but had a misconfigured certificate,
> and the only way to access those services was to override the browser
> complaints. Today (working at Dropbox, a much sma
Glenn Linderman writes:
> Well, this thread seems to be top-posted so...
Not a good enough reason for me!
> Why not provide _urlopen_with_scary_keyword_parameter as the
> monkey-patch option?
>
> So after the (global to the module) monkeypatch, they would _still_ have
> to add the k
Jeff Allen writes:
> A welcome article. One correction should be made, I believe: the area of
> code point space used for the smuggling of bytes under PEP-383 is not a
> "Unicode Private Use Area", but a portion of the trailing surrogate
> range.
Nice catch. Note that the surrogate range
Jeff Allen writes:
> Simply having a block "for private use" seems to create an unmanaged
> space for conflict,
No. The uncharted range of human language (including recently-
invented nonsense like "emoticons" and the annual "design a character"
contest run by a newpaper in Taipei, with the g
Jim J. Jewett writes:
> In terms of best-effort, it is reasonable to treat the smuggled bytes
> as representing a character outside of your unicode repertoire
I have to disagree. If you ever end up passing them to something that
validates or tries to reencode them without surrogateescape, BOOM
1 - 100 of 1553 matches
Mail list logo
