On 29 Nov 2021, at 23:56, Barry Warsaw wrote:
[...]
(not that you're not allowed to use for anything else, of course you
are, but that other uses won;t be taken into account when designing
the new interface)
But I have never seen that clearly stated anywhere. The closest is
from PEP 563, wh
On 16 Apr 2021, at 19:38, Jelle Zijlstra wrote:
El vie, 16 abr 2021 a las 10:01, Walter Dörwald
()
escribió:
On 16 Apr 2021, at 16:59, Guido van Rossum wrote:
If you look deeper, the real complaints are all about the backwards
incompatibility when it comes to locally-scoped types in
On 16 Apr 2021, at 16:59, Guido van Rossum wrote:
If you look deeper, the real complaints are all about the backwards
incompatibility when it comes to locally-scoped types in annotations.
I.e.
def test():
class C: ...
def func(arg: C): ...
return func
typing.get_type_hints(test()) # r
On 2 Feb 2021, at 12:36, Stefano Borini wrote:
Hi all,
I would like to request feedback by python-dev on the current
implementation of PEP 637 - Support for indexing with keyword
arguments.
https://www.python.org/dev/peps/pep-0637/
The PEP is ready for SC submission and it has a prototype
imp
On 7 Oct 2020, at 1:27, Victor Stinner wrote:
Hi Walter,
https://github.com/python/cpython/commit/a8bf44d04915f7366d9f8dfbf84822ac37a4bab3
Le mar. 6 oct. 2020 à 17:02, Walter Dörwald
a écrit :
It would be even simpler to use unicodedata.lookup() which returns
the unicode character when
On 6 Oct 2020, at 16:22, Florian Bruhin wrote:
https://github.com/python/cpython/commit/a8bf44d04915f7366d9f8dfbf84822ac37a4bab3
commit: a8bf44d04915f7366d9f8dfbf84822ac37a4bab3
branch: master
author: Florian Bruhin
committer: GitHub
date: 2020-10-06T16:21:56+02:00
summary:
bpo-41944: No long
On 1 Jul 2020, at 18:54, Brandt Bucher wrote:
Walter Dörwald wrote:
This looks strange to me. In all other cases of variable lookup the
global variable z would be found.
The next case assigns to z, making z local to whereis. This is
consistent with python's existing scoping rules
On 1 Jul 2020, at 17:58, Guido van Rossum wrote:
If you are interested in learning more about how PEP 622 would work in
practice, but don't feel like compiling a Python 3.10 fork from
source,
here's good news for you.
In a hurry?
https://mybinder.org/v2/gh/gvanrossum/patma/master?urlpath=lab/
On 25 Mar 2020, at 9:48, Stephen J. Turnbull wrote:
Walter Dörwald writes:
A `find()` that supports multiple search strings (and returns the
leftmost position where a search string can be found) is a great help
in
implementing some kind of tokenizer:
In other words, you want the
On 24 Mar 2020, at 2:42, Steven D'Aprano wrote:
On Sun, Mar 22, 2020 at 10:25:28PM -, Dennis Sweeney wrote:
Changes:
- More complete Python implementation to match what the type
checking in the C implementation would be
- Clarified that returning ``self`` is an optimization
-
On 21 Mar 2020, at 19:09, Steven D'Aprano wrote:
On Sat, Mar 21, 2020 at 12:15:21PM -0400, Eric V. Smith wrote:
On 3/21/2020 11:20 AM, Ned Batchelder wrote:
Why be so prescriptive? The semantics of these functions should be
about what the resulting string contains. Leave it to implementors
On 11 Dec 2019, at 12:12, Mark Shannon wrote:
Hi everyone,
Thanks for all your feedback so far.
Previously I asked for "more precise" feedback, which has been
interpreted as evidence backed feedback. That's not what I meant.
My fault for not being clearer.
Your opinions without any justific
On 20 May 2019, at 22:15, Christian Heimes wrote:
Hi,
here is the first version of my PEP 594 to deprecate and eventually
remove modules from the standard library. The PEP started last year
with talk during the Python Language Summit 2018,
https://lwn.net/Articles/755229/.
[...]
colorsys
On 18 Jan 2019, at 11:57, Antoine Pitrou wrote:
On Fri, 18 Jan 2019 03:00:54 +
MRAB wrote:
On 2019-01-18 00:48, Gregory P. Smith wrote:
I've heard that libraries using ctypes, cffi, or cython code of
various
sorts in the real world wild today does abuse the unfortunate side
effect of CPy
On 13 Sep 2018, at 2:33, Victor Stinner wrote:
Hi,
For the type name, sometimes, we only get a type (not an instance),
and we want to format its FQN. IMHO we need to provide ways to format
the FQN of a type for *types* and for *instances*. Here is my
proposal:
* Add !t conversion to format str
On 23 Sep 2017, at 3:09, Eric Snow wrote:
[...]
``list_all()``::
Return a list of all existing interpreters.
See my naming proposal in the previous thread.
Sorry, your previous comment slipped through the cracks. You
suggested:
As for the naming, let's make it both unconfusing a
, or by specifying a base package name or regular expression, i.e.
report the innermost stackframe that is not from
"mypackage.mysubpackage").
See http://bugs.python.org/issue850482
Bye,
Walter Dörwald
___
Python-Dev mailing list
Pytho
On 28 Apr 2015, at 5:07, Yury Selivanov wrote:
Hi python-dev,
Another round of updates. Reference implementation
has been updated: https://github.com/1st1/cpython/tree/await
(includes all things from the below summary of updates +
tests).
[...]
New Coroutine Declaration Syntax
---
ind() your patch
takes care of business.
Did you see anything in particular?
No, I was just using inspect.signature lately and reading the PEP
reminded me of it.
Best,
Neil
Servus,
Walter
On Thu, Jan 22, 2015 at 12:23 PM, Walter Dörwald
wrote:
On 20 Jan 2015, at 17:34, Neil Gir
On 20 Jan 2015, at 17:34, Neil Girdhar wrote:
> My question first:
> test_ast is mostly generated code, but I can't find where it is being
> generated. I am pretty sure I know how to fix most of the introduced
> problems. Who is generating test_ast??
>
> Update:
>
> So far, I've done the followi
On 28 Aug 2014, at 19:54, Glenn Linderman wrote:
On 8/28/2014 10:41 AM, R. David Murray wrote:
On Thu, 28 Aug 2014 10:15:40 -0700, Glenn Linderman
wrote:
[...]
Also for
cases where the data stream is *supposed* to be in a given encoding,
but
contains undecodable bytes. Showing the stuff tha
On 8 Jul 2014, at 15:52, Ben Hoyt wrote:
Hi folks,
After some very good python-dev feedback on my first version of PEP
471, I've updated the PEP to clarify a few things and added various
"Rejected ideas" subsections. Here's a link to the new version (I've
also copied the full text below):
http
On 28 Jun 2014, at 21:48, Ben Hoyt wrote:
[...]
Crazy idea: would it be possible to "convert" a DirEntry object to a
pathlib.Path object without losing the cache? I guess that
pathlib.Path expects a full stat_result object.
The main problem is that pathlib.Path objects explicitly don't cache
On 04.01.14 13:58, Serhiy Storchaka wrote:
Should implicit converting an instance of int, float, complex, str,
bytes, etc subclasses to call appropriate special method __int__ (or
__index__), __float__, __complex__, __str__, __bytes__, etc? Currently
explicit converting calls these methods, but
On 15.12.13 17:33, Ethan Furman wrote:
On 12/14/2013 07:51 PM, Steven D'Aprano wrote:
On Sun, Dec 15, 2013 at 11:25:10AM +1000, Nick Coghlan wrote:
Oh, yes, a %T shortcut for "length limited type name of the supplied
object" would be brilliant. We need this frequently for C level error
message
On 20.11.13 02:28, Jim J. Jewett wrote:
[...]
Instead of relying on introspection of .decodes_to and .encodes_to, it
would be useful to have charsetcodecs and tranformcodecs as entirely
different modules, with their own separate registries. I will even
note that the existing help(codecs) seems
On 15.11.13 00:02, Greg Ewing wrote:
Walter Dörwald wrote:
Unfortunaty the frame from the decorator shows up in the traceback.
Maybe the decorator could remove its own frame from
the traceback?
True, this could be done via either an additional attribute on the
frame, or a special value
Am 15.11.2013 um 16:57 schrieb "Stephen J. Turnbull" :
>
> Walter Dörwald writes:
>>> Am 15.11.2013 um 00:42 schrieb Serhiy Storchaka :
>>>
>>> 15.11.13 00:32, Victor Stinner написав(ла):
>>>> And add transform() and untransform() method
Am 15.11.2013 um 00:42 schrieb Serhiy Storchaka :
>
> 15.11.13 00:32, Victor Stinner написав(ла):
>> And add transform() and untransform() methods to bytes and str types.
>> In practice, it might be same codecs registry for all codecs just with
>> a new attribute.
>
> If the transform() method wi
On 14.11.13 14:22, Walter Dörwald wrote:
On 13.11.13 17:25, Nick Coghlan wrote:
>> [...]
A more elegant (and comprehensive) solution as a PEP for 3.5 would
certainly be a nice thing to have, but I think this is still much
better than the 3.3 status quo.
Thinking further about this,
On 13.11.13 17:25, Nick Coghlan wrote:
On 14 November 2013 02:12, Nick Coghlan wrote:
On 14 November 2013 00:30, Walter Dörwald wrote:
On 13.11.13 14:51, nick.coghlan wrote:
http://hg.python.org/cpython/rev/854a2cea31b9
changeset: 87084:854a2cea31b9
user:Nick Coghlan
date
On 13.11.13 14:51, nick.coghlan wrote:
http://hg.python.org/cpython/rev/854a2cea31b9
changeset: 87084:854a2cea31b9
user:Nick Coghlan
date:Wed Nov 13 23:49:21 2013 +1000
summary:
Close #17828: better handling of codec errors
- output type errors now redirect users to the ty
On 23.09.13 17:18, Skip Montanaro wrote:
It would be great if the docstring contained a link to the online
documentation.
That would have to be a feature of help(), not hardcoded in each docstring.
That *is* a feature of the help function:
Help on built-in module sys:
help(sys)
NAME
On 23.09.13 15:38, Fred Drake wrote:
On Mon, Sep 23, 2013 at 7:27 AM, Walter Dörwald wrote:
It would be great if the docstring contained a link to the online
documentation.
The docstring itself, or the presentation generated by help() ?
The presentation generated by help(), or the output
On 22.09.13 16:34, Brett Cannon wrote:
The rule of thumb I go by is the docstring should be enough to answer
the question "what args does this thing take and what does it do in
general to know it's the function I want and another one in the same
module?" quickly and succinctly; i.e. just enough
On 17.06.13 19:04, Walter Dörwald wrote:
Hmm, it seems that codecs.unicode_escape_decode() does what I want:
>>> codecs.unicode_escape_decode("\r\n\\r\\n\\x0d\\x0a\\u000d\\u000a")
('\r\n\r\n\r\n\r\n', 26)
Hmm, no it doesn't:
>>> codecs.unicode_es
On 14.06.13 23:03, PJ Eby wrote:
On Fri, Jun 14, 2013 at 2:11 PM, Ron Adam wrote:
On 06/14/2013 10:36 AM, Guido van Rossum wrote:
Not a bug. The same is done for file input -- CRLF is changed to LF before
tokenizing.
Should this be the same?
python3 -c 'print(bytes("""\r\n""", "utf8")
Hello all!
This surprised me:
>>> eval("'''\r\n'''")
'\n'
Where did the \r go? ast.literal_eval() has the same problem:
>>> ast.literal_eval("'''\r\n'''")
'\n'
Is this a bug/worth fixing?
Servus,
Walter
___
Python-Dev mailing list
Py
On 23.05.13 00:33, Łukasz Langa wrote:
Hello,
I would like to submit the following PEP for discussion and evaluation.
PEP: 443
Title: Single-dispatch generic functions
[...]
>>> @fun.register(int)
... def _(arg, verbose=False):
... if verbose:
... print("Strength in num
Am 27.03.2013 um 03:24 schrieb R. David Murray :
> On Tue, 26 Mar 2013 16:59:06 -0700, Maciej Fijalkowski
> wrote:
>> On Tue, Mar 26, 2013 at 4:49 PM, Sean Felipe Wolfe
>> wrote:
>>> Hey everybody how are you all :)
>>>
>>> I am an intermediate-level python coder looking to get help out. I'v
On 26.09.12 16:43, ezio.melotti wrote:
http://hg.python.org/cpython/rev/36f61661f71e
changeset: 79194:36f61661f71e
user:Ezio Melotti
date:Wed Sep 26 17:43:23 2012 +0300
summary:
Add a few entries to whatsnew/3.3.rst.
[...]
+
+A new :data:`~html.entities.html5` dictionary th
On 04.06.12 13:19, Dirkjan Ochtman wrote:
I recently opened issue14908. At work, I have to do a bunch of things
with dates, times and timezones, and sometimes Unix timestamps are
also involved (largely for easy compatibility with legacy APIs). I
find the relative obscurity when converting dateti
Am 03.02.2012 um 01:59 schrieb Nick Coghlan :
> On Fri, Feb 3, 2012 at 10:21 AM, Victor Stinner
> wrote:
>> I updated and completed my PEP and published the last draft. It will
>> be available at:
>> http://www.python.org/dev/peps/pep-0410/
>> ( or read the source: http://hg.python.org/peps/file/
On 24.05.11 12:58, Victor Stinner wrote:
> Le mardi 24 mai 2011 à 12:42 +0200, Łukasz Langa a écrit :
>> Wiadomość napisana przez Walter Dörwald w dniu 2011-05-24, o godz. 12:16:
>>
>>>> I don't see which usecase is not covered by TextIOWrapper. But I know
>>
On 24.05.11 02:08, Victor Stinner wrote:
> [...]
> codecs.open() and StreamReader, StreamWriter and StreamReaderWriter
> classes of the codecs module don't support universal newlines, still
> have some issues with stateful codecs (like UTF-16/32 BOMs), and each
> codec has to implement a StreamRea
On 12.05.11 18:33, s...@pobox.com wrote:
> A friend at work who is new to Python wondered why this didn't work with
> pickle:
>
> class Outer:
>
> Class Inner:
>
> ...
>
> def __init__(self):
> self.i = Outer.Inner()
>
> I explained:
>
>> http://do
On 12.05.11 18:53, Walter Dörwald wrote:
> On 12.05.11 18:33, s...@pobox.com wrote:
>
>> A friend at work who is new to Python wondered why this didn't work with
>> pickle:
>>
>> class Outer:
>>
>> Class Inner:
>&g
On 03.11.10 19:21, anatoly techtonik wrote:
> Hi,
>
> Python code coverage doesn't include any .py files. What happened?
> http://coverage.livinglogic.de/
>
> Did it work before?
It did, however currently the logfile
http://coverage.livinglogic.de/testlog.txt
shows the following exception:
On 06.07.10 15:07, Mark Dickinson wrote:
> On Tue, Jul 6, 2010 at 1:10 PM, Walter Dörwald wrote:
>> http://coverage.livinglogic.de/ *does* include coverage info for stuff
>> written in C, see for example:
>>
>> http://coverage.livinglogic.de/Objects/unicodeobject.
On 05.07.10 16:19, Nick Coghlan wrote:
> On Mon, Jul 5, 2010 at 5:20 AM, Terry Reedy wrote:
>> On 7/4/2010 2:31 AM, Éric Araujo wrote:
But Python tests lack coverage stats, so it is hard to say anything.
>>>
>>> FYI: http://coverage.livinglogic.de/
>>
>> Turns out the audioop is one of t
Am 18.06.2010 um 22:53 schrieb Terry Reedy :
On 6/18/2010 12:32 PM, Walter Dörwald wrote:
http://coverage.livinglogic.de/
I am a bit puzzled as to the meaning of the gray/red/green bars
since the correlation between coverage % and bars is not very high.
The gray bar is the
On 18.06.10 17:04, Brian Curtin wrote:
> [...]
> 2. no code coverage (test/user story/rfc/pep)
>
>
> If you know of a way to incorporate code coverage tools and metrics into
> the current process, I believe a number of people would be interested.
> There currently exists some coverage tool t
On 10.06.10 21:31, Terry Reedy wrote:
> On 6/10/2010 7:08 AM, M.-A. Lemburg wrote:
>> Walter Dörwald wrote:
>
>>>> The PEP would also serve as a reference back to both this discussion and
>>>> the previous one (which was long enough ago that I've forgott
On 09.06.10 14:47, Nick Coghlan wrote:
> On 09/06/10 22:18, Victor Stinner wrote:
>> Le mercredi 09 juin 2010 10:41:29, M.-A. Lemburg a écrit :
>>> No, .transform() and .untransform() will be interface to same-type
>>> codecs, i.e. ones that convert bytes to bytes or str to str. As with
>>> .encod
On 11.01.10 13:45, Lennart Regebro wrote:
> On Mon, Jan 11, 2010 at 13:29, Walter Dörwald wrote:
>> However if this autodetection feature is useful in other cases (no
>> matter how it's activated), it should be a codec, because as part of the
>> open() function it i
On 10.01.10 00:40, "Martin v. Löwis" wrote:
>>> How does the requirement that it be implemented as a codec miss the
>>> point?
>>
>> If we want it to be the default, it must be able to fallback on the current
>> locale-based algorithm if no BOM is found. I don't think it would be easy
>> for a
>>
On 09.01.10 14:38, Victor Stinner wrote:
> Le samedi 09 janvier 2010 12:18:33, Walter Dörwald a écrit :
>>> Good idea, I choosed open(filename, encoding="BOM").
>>
>> On the surface this looks like there's an encoding named "BOM", but
>> loo
Victor Stinner wrote:
Le vendredi 08 janvier 2010 10:10:23, Martin v. Löwis a écrit :
Builtin open() function is unable to open an UTF-16/32 file starting with
a BOM if the encoding is not specified (raise an unicode error). For an
UTF-8 file starting with a BOM, read()/readline() returns also t
On 09.01.10 01:47, Glenn Linderman wrote:
> On approximately 1/8/2010 3:59 PM, came the following characters from
> the keyboard of Victor Stinner:
>> Hi,
>>
>> Thanks for all the answers! I will try to sum up all ideas here.
>
> One concern I have with this implementation encoding="BOM" is that
Stephen J. Turnbull wrote:
> Walter Dörwald writes:
>
> > "surrogatepass" (for the "don't complain about lone half surrogates"
> > handler) and "surrogatereplace" sound OK to me. However the other
> > "...replace" handlers ar
Michael Urman wrote:
> [...]
>> Well, there is a way to stack error handlers, although it's not pretty:
>> [...]
>> codecs.register_error("surrogates_then_replace",
>> surrogates_then_replace)
>
> That mitigates my arguments significantly, although I'd rather see
> something
M.-A. Lemburg wrote:
> Antoine Pitrou wrote:
>> Martin v. Löwis v.loewis.de> writes:
>>> py> b'\xed\xa0\x80'.decode("utf-8","surrogates")
>>> '\ud800'
>> The point is, "surrogates" does not mean anything intuitive for an /error
>> handler/. You seem to be the only one who finds this name explicit
Martin v. Löwis wrote:
>> "correct" -> "corrected"
>
> Thanks, fixed.
>
>>> To convert non-decodable bytes, a new error handler "python-escape" is
>>> introduced, which decodes non-decodable bytes using into a private-use
>>> character U+F01xx, which is believed to not conflict with private-use
>
Martin v. Löwis wrote:
> I'm proposing the following PEP for inclusion into Python 3.1.
> Please comment.
>
> Regards,
> Martin
>
> PEP: 383
> Title: Non-decodable Bytes in System Character Interfaces
> Version: $Revision: 71793 $
> Last-Modified: $Date: 2009-04-22 08:42:06 +0200 (Mi, 22. Apr 20
C. Titus Brown wrote:
> [...]
> I have had a hard time getting a good sense of what core code is well
> tested and what is not well tested, across various platforms. While
> Walter's C/Python integrated code coverage site is nice, it would be
> even nicer to have a way to generate all that inform
Paul Moore wrote:
2009/1/30 Walter Dörwald :
Paul Moore wrote:
[...]
In all honesty, I think pkgutil.simplegeneric should be documented,
exposed, and moved to a library of its own[1].
http://pypi.python.org/pypi/simplegeneric
Thanks, I was aware of that.
I wasn't aware of the fact
Paul Moore wrote:
> [...]
> In all honesty, I think pkgutil.simplegeneric should be documented,
> exposed, and moved to a library of its own[1].
http://pypi.python.org/pypi/simplegeneric
> [...]
Servus,
Walter
___
Python-Dev mailing list
Python-De
Hello all!
The code coverage site at http://coverage.livinglogic.de/ was broken for
the last few months. It's fixed again now and runs the test suite once
per day with
regrtest.py -T -N -uurlfetch,largefile,network,decimal
Servus,
Walter
___
Pyth
Walter Dörwald wrote:
[...]
Sure, we could do that, but please use a different name,
e.g. .encodeall() and .decodeall() - .encode() and .decode()
are already stateles (and so would the new methods be), so
"stateless" isn't all that meaningful in this context.
I like the
M.-A. Lemburg wrote:
On 2008-06-13 11:32, Walter Dörwald wrote:
M.-A. Lemburg wrote:
On 2008-06-12 16:59, Walter Dörwald wrote:
M.-A. Lemburg wrote:
.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does
M.-A. Lemburg wrote:
On 2008-06-12 16:59, Walter Dörwald wrote:
M.-A. Lemburg wrote:
.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does indeed return the same type.
E.g. text.transform('xml-escape
M.-A. Lemburg wrote:
On 2008-06-11 17:15, Walter Dörwald wrote:
M.-A. Lemburg wrote:
On 2008-06-11 13:35, Barry Warsaw wrote:
So I had planned to do a bunch of work last night looking at the
release blocker issues, but nature intervened. A bunch of severe
thunderstorms knock out my
M.-A. Lemburg wrote:
On 2008-06-11 13:35, Barry Warsaw wrote:
So I had planned to do a bunch of work last night looking at the
release blocker issues, but nature intervened. A bunch of severe
thunderstorms knock out my 'net access until this morning.
I'll try to find some time during the day
Christian Heimes wrote:
> [...]
> PEP: XXX
> Title: Per user site-packages directory
> Version: $Revision$
> Last-Modified: $Date$
> Author: Christian Heimes
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 11-Jan-2008
> Python-Version: 2.6, 3.0
> Post-History:
> [..
Fred Drake wrote:
> On Nov 12, 2007, at 8:56 AM, Walter Dörwald wrote:
>> It isn't "embedded". codecs.detect_xml_encoding() is callable without
>> any problems (though not documented).
>
> "Not documented" means not available, I think.
I just din
Fred Drake wrote:
> On Nov 12, 2007, at 8:16 AM, M.-A. Lemburg wrote:
>> We have a -1 from Martin and a +1 from Walter, Guido and myself.
>> Pretty clear vote if you ask me. I'd say we end the discussion here
>> and move on.
>
> If we're counting, you've got a -1 on the codec from me as well.
Martin v. Löwis wrote:
>> > In case it isn't clear - this is exactly my view also.
>>
>> But is there an API to do it? As MAL points out that API would have
>> to return not an encoding, but a pair of an encoding and the rewound
>> stream.
>
> The API wouldn't operate on streams. Instead, you
Martin v. Löwis wrote:
>> I don't know. Is an XML document ill-formed if it doesn't contain an
>> XML declaration, is not in UTF-8 or UTF-8, but there's external
>> encoding info?
>
> If there is external encoding info, matching the actual encoding,
> it would be well-formed. Of course, preserving
"Martin v. Löwis" sagte:
>> And what do you do once you've detected the encoding? You decode the
>> input, so why not combine both into an XML decoder?
>
> Because it is the XML parser that does the decoding, not the
> application. Also, it is better to provide functionality in
> a modular manner
"Martin v. Löwis" sagte:
>>> So what if the unicode string doesn't start with an XML declaration?
>>> Will it add one?
>>
>> No.
>
> Ok. So the XML document would be ill-formed then unless the encoding is
> UTF-8, right?
I don't know. Is an XML document ill-formed if it doesn't contain an XML
d
M.-A. Lemburg wrote:
> On 2007-11-09 14:10, Walter Dörwald wrote:
>> Martin v. Löwis wrote:
>>>>> Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc
>>>>> codecs to do the encoding. There's no need to create a magical
>>>&
Walter Dörwald wrote:
> Martin v. Löwis wrote:
>>>> Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc
>>>> codecs to do the encoding. There's no need to create a magical
>>>> mystery codec to pick out which though.
>>> So the
Martin v. Löwis wrote:
>>> Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc
>>> codecs to do the encoding. There's no need to create a magical
>>> mystery codec to pick out which though.
>> So the code is good, if it is inside an XML parser, and it's bad if it
>> is inside a cod
Martin v. Löwis wrote:
>> Because you can force the encoder to use a specified encoding. If you do
>> this and the unicode string starts with an XML declaration
>
> So what if the unicode string doesn't start with an XML declaration?
> Will it add one?
No.
> If so, what version number will it u
Martin v. Löwis wrote:
>> ci = codecs.lookup("xml-auto-detect")
>> p = expat.ParserCreate()
>> e = "utf-32"
>> s = (u"" % e).encode(e)
>> s = ci.encode(ci.decode(s)[0], encoding="utf-8")[0]
>> p.Parse(s, True)
>
> So how come the document being parsed is recognized as UTF-8?
Because you can forc
Adam Olsen wrote:
> On 11/8/07, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> [...]
>>>> Furthermore encoding-detection might be part of the responsibility of
>>>> the XML parser, but this decoding phase is totally distinct from the
>>>> parsi
Walter Dörwald wrote:
> Martin v. Löwis wrote:
>
> [...]
>>> Correct, but as long as Python doesn't have an EBCDIC codec, that won't
>>> help much. Adding *detection* of EBCDIC to detect_xml_encoding() is
>>> rather simple though.
>> But it do
Martin v. Löwis wrote:
>> Then how about the suggested "xml-auto-detect"?
>
> That is better.
OK.
>>> Then, I'd claim that the problem that the codec solves doesn't really
>>> exist. IOW, most XML parsers implement the auto-detection of encodings,
>>> anyway, and this is where architecturally t
Martin v. Löwis wrote:
>> Any comments?
>
> -1. First, (as already discussed on the tracker,) "xml" is a bad name
> for an encoding. How would you encode "Hello" "in xml"?
Then how about the suggested "xml-auto-detect"?
> Then, I'd claim that the problem that the codec solves doesn't really
> ex
I have a patch ready (http://bugs.python.org/issue1399) that adds an XML
codec. This codec implements encoding detection as specified in
http://www.w3.org/TR/2004/REC-xml-20040204/#sec-guessing and could be
used for the decoding phase of an XML parser. Other use cases are:
The codec could be used
[EMAIL PROTECTED] wrote:
> On the community trunk buildbots this checkin:
>
>1.
>
> Changed by: walter.doerwald
> Changed at: Tue 28 Aug 2007 16:38:27
> Branch: trunk
> Revision: 57620
>
> Changed files:
> * trunk/Doc/library/calendar.rst
>
Neal Norwitz wrote:
> Martin,
>
> Do you know why T_PYSSIZET is inside a #ifdef HAVE_LONG_LONG? That
> seems like a mistake. Here's the code:
>
> #ifdef HAVE_LONG_LONG
> #define T_LONGLONG 17
> #define T_ULONGLONG 18
> #define T_PYSSIZET 19 /* Py_ssize_t */
> #endif /* HAVE_LONG_
Giovanni Bajo wrote:
> On 09/07/2007 21.23, Walter Dörwald wrote:
>
>> >>> from ll.xist import parsers, xfind
>> >>> from ll.xist.ns import html
>> >>> e = parsers.parseURL("http://www.python.org";, tidy=True)
>> >&g
Raymond Hettinger wrote:
> From: "Guido van Rossum" <[EMAIL PROTECTED]>
>> But doesn't the very same argument also apply against islice(), which
>> you just offered as an alternative?
>
> Not really. The use cases for islice() typically do not involve
> repeated slices of an iterator unless it i
Guido van Rossum wrote:
> On 7/9/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> Also, as a practical matter, I think it is a bad idea to introduce
>> __getitem__ style access to itertools because the starting point
>> moves with each consecutive access:
>>
>> # access items 0, 2, 5, 9, 14,
Raymond Hettinger wrote:
> [Walter Dörwald]
>> I'd like to propose the following addition to itertools: A function
>> itertools.getitem() which is basically equivalent to the following
>> python code:
>>
>> _default = object()
>>
>> def get
Guido van Rossum wrote:
> On 7/8/07, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> [quoting Guido]
>> > But I still want to hear of a practical use case for the default here.
>>
>> In most cases
>>
>> foo = getitem(iterable, 0, None)
>>
Guido van Rossum wrote:
> On 7/8/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum schrieb:
>>> How important is it to have the default in this API? __getitem__()
>>> doesn't have a default; instead, there's a separate API get() that
>>> provides a default (and I find defaulting to No
I'd like to propose the following addition to itertools: A function
itertools.getitem() which is basically equivalent to the following
python code:
_default = object()
def getitem(iterable, index, default=_default):
try:
return list(iterable)[index]
except IndexError:
if d
Georg Brandl wrote:
> Walter Dörwald schrieb:
>> Georg Brandl wrote:
>>> Nick Coghlan schrieb:
>>>> Georg Brandl wrote:
>>>>> Guido van Rossum schrieb:
>>>>>> I've written up a comprehensive status report on Python 3000. Please
&
1 - 100 of 212 matches
Mail list logo
