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,
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
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()) #
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
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
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?
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
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
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
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
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
rn()
is), 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
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
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
wal...@livinglogic.de
wrote:
On 20 Jan 2015, at 17:34
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 following:
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
v+pyt...@g.nevcal.com wrote:
[...]
Also for
cases where the data stream is *supposed* to be in a given encoding,
but
contains undecodable bytes.
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):
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
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 step...@xemacs.org:
Walter Dörwald writes:
Am 15.11.2013 um 00:42 schrieb Serhiy Storchaka storch...@gmail.com:
15.11.13 00:32, Victor Stinner написав(ла):
And add transform() and untransform() methods to bytes and str types.
In practice
On 13.11.13 17:25, Nick Coghlan wrote:
On 14 November 2013 02:12, Nick Coghlan ncogh...@gmail.com wrote:
On 14 November 2013 00:30, Walter Dörwald wal...@livinglogic.de wrote:
On 13.11.13 14:51, nick.coghlan wrote:
http://hg.python.org/cpython/rev/854a2cea31b9
changeset: 87084
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, I like
Am 15.11.2013 um 00:42 schrieb Serhiy Storchaka storch...@gmail.com:
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()
On 13.11.13 14:51, nick.coghlan wrote:
http://hg.python.org/cpython/rev/854a2cea31b9
changeset: 87084:854a2cea31b9
user:Nick Coghlan ncogh...@gmail.com
date:Wed Nov 13 23:49:21 2013 +1000
summary:
Close #17828: better handling of codec errors
- output type errors now
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 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 23.09.13 15:38, Fred Drake wrote:
On Mon, Sep 23, 2013 at 7:27 AM, Walter Dörwald wal...@livinglogic.de 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
On 14.06.13 23:03, PJ Eby wrote:
On Fri, Jun 14, 2013 at 2:11 PM, Ron Adam ron3...@gmail.com 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
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_escape_decode(\u1234)
('á\x88´', 3)
Servus,
Walter
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
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
Am 27.03.2013 um 03:24 schrieb R. David Murray rdmur...@bitdance.com:
On Tue, 26 Mar 2013 16:59:06 -0700, Maciej Fijalkowski fij...@gmail.com
wrote:
On Tue, Mar 26, 2013 at 4:49 PM, Sean Felipe Wolfe ether@gmail.com
wrote:
Hey everybody how are you all :)
I am an intermediate-level
On 26.09.12 16:43, ezio.melotti wrote:
http://hg.python.org/cpython/rev/36f61661f71e
changeset: 79194:36f61661f71e
user:Ezio Melotti ezio.melo...@gmail.com
date:Wed Sep 26 17:43:23 2012 +0300
summary:
Add a few entries to whatsnew/3.3.rst.
[...]
+
+A new
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
Am 03.02.2012 um 01:59 schrieb Nick Coghlan ncogh...@gmail.com:
On Fri, Feb 3, 2012 at 10:21 AM, Victor Stinner
victor.stin...@haypocalc.com 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
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 StreamReader
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
some cases which are not supported
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:
...
def __init__(self):
self.i = Outer.Inner()
I
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:
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 05.07.10 16:19, Nick Coghlan wrote:
On Mon, Jul 5, 2010 at 5:20 AM, Terry Reedy tjre...@udel.edu 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 the
On 06.07.10 15:07, Mark Dickinson wrote:
On Tue, Jul 6, 2010 at 1:10 PM, Walter Dörwald wal...@livinglogic.de wrote:
http://coverage.livinglogic.de/ *does* include coverage info for stuff
written in C, see for example:
http://coverage.livinglogic.de/Objects/unicodeobject.c.html
However
Am 18.06.2010 um 22:53 schrieb Terry Reedy tjre...@udel.edu:
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
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 that
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 forgotten most of
it).
I too think that a PEP is required
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
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
looking at your patch I found that the check is still done
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
codec to do that.
On 11.01.10 13:45, Lennart Regebro wrote:
On Mon, Jan 11, 2010 at 13:29, Walter Dörwald wal...@livinglogic.de 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 isn't reusable
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 if
there
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
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 are destructive (i.e. when such a ...replace
handler is used for encoding, decoding
M.-A. Lemburg wrote:
Antoine Pitrou wrote:
Martin v. Löwis martin at 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 enough,
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 like
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 2009) $
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
characters that
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
Paul Moore wrote:
2009/1/30 Walter Dörwald wal...@livinglogic.de:
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
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
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
___
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-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
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 names encodeall
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 'net
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
Christian Heimes wrote:
[...]
PEP: XXX
Title: Per user site-packages directory
Version: $Revision$
Last-Modified: $Date$
Author: Christian Heimes christian(at)cheimes(dot)de
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Jan-2008
Python-Version: 2.6, 3.0
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't think that someone wants the detection function
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 that
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 pass a
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 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
declaration, is
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 (i.e.
Martin v. Löwis wrote:
ci = codecs.lookup(xml-auto-detect)
p = expat.ParserCreate()
e = utf-32
s = (u?xml version='1.0' encoding=%r?foo/ % 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?
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
parsing phase, so why not put the decoding into a common library?
I would
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 use?
If
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 codec?
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 code is good, if it is inside an XML parser, and it's bad
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
mystery codec to pick out which though.
So the code is good
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
exist. IOW, most
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 this
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_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)
print e.walknode(html.h2 xfind.hasclass(news))[-1]
Google Adds Python Support to Google Calendar
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 getitem(iterable, index, default=_default):
try:
return list
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, 20, ...
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 is slicing
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
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 None more
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)
if foo is not None:
...
is simpler than:
try
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 read:
http://www.artima.com/weblogs/viewpost.jsp?thread=208549
Thank you! Now I have something to show to interested people except
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
read:
http://www.artima.com/weblogs/viewpost.jsp?thread=208549
Thank you! Now I have
1 - 100 of 211 matches
Mail list logo
