For those that haven't seen this:
http://www.utf8everywhere.org/
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Donald Stufft
> Sent: 4. júní 2014 01:46
> To: Steven D'Aprano
> Cc: python-dev@python.org
> Subject: Re: [
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Chris Withers
> Sent: 24. apríl 2014 07:18
> To: Python-Dev
> Subject: [Python-Dev] pep8 reasoning
> The biggest sticking point is naming, particularly as it's the one thin
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Armin Rigo
> Sent: 21. apríl 2014 07:42
> To: Nick Coghlan
> Cc: Python-Dev
> Subject: Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items()
> methods
>
> How ab
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Steven
> D'Aprano
> If this is a cunning plan to make Nick's suggestion sound better by suggesting
> an even worse alternative, it's working :-)
You got me.
However, I als
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Steven
> On Sat, Apr 19, 2014 at 11:41:35AM +0000, Kristján Valur Jónsson wrote:
> > Wouldn't "iterkeys" simply be an alias for &qu
Original message
From: Steven D'Aprano
Date:20/04/2014 17:05 (GMT+00:00)
To: python-dev@python.org
Subject: Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Sun, Apr 20, 2014 at 03:07:39PM +, Kristján Valur Jónsson wrote:
> Does one ever use it
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Eric Snow
> Sent: 19. apríl 2014 23:15
> To: Barry Warsaw
> Cc: Python-Dev
> Subject: Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items()
> methods
> > I agree.
> -Original Message-
> From: Nick Coghlan [mailto:ncogh...@gmail.com]
>
> > 2. Feature enhancement to 2.8. Take a robust and popular version of
> > python and add some of the language goodies that have been added to
> > 3.x and that don’t have an inherent 3.x aspect. Yield from.
Wouldn't "iterkeys" simply be an alias for "keys" and so on?
I'm +1 on that.
It is a signigificant portion of the incompatibility, and seems like such a
minor concession to compatibility to make.
K
-Original Message-
From: Python-Dev [mailto:python-dev-bounces+kristjan=ccpgames@python
Here, a week later, are some of my thoughts from the summit, for the record:
2.8:
The issue of a hyptothetical 2.8 never fails to entertain. However, I noticed
that there seem to be at least two distinct missions of such a thing.
1. An aid in the conversion from 2.x series to 3.x series.
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Antoine Pitrou
> Sent: 27. mars 2014 15:53
> To: python-dev@python.org
> Subject: Re: [Python-Dev] collections.sortedtree
>
> On Thu, 27 Mar 2014 08:50:01 -0700
> Daniel S
for our stackless socket framework we have the same issue.
Windows provides an opaque timer system where a timer can be cancelled by
handle. But on linux one has to
craft one's own.
One thing with this particular use case is that a heapq is overkill for network
timer. . For network timers a g
True.
I've long since added a heapdel() to our local fork.
a heappop(idx=0) extension would do the same
I can provide a patch if there is interest.
K
Ideally, I think you should be able to replace the cancelled item with
the last item in the heap and then fix the heap in logarithmic time,
but the
...@midwinter.com] On Behalf Of Larry Hastings
Sent: 24. mars 2014 01:33
To: Kristján Valur Jónsson
Subject: Fwd: Re: [Python-Dev] cpython (3.3): Make the various iterators'
"setstate" sliently and consistently clip the
Still no reply on this...? I'd like to see your
+1
Also, for the equivalence to hold there is no separate Py_XSETREF, the X
behaviour is implied, which I favour. Enough of this X-proliferation already!
But also see the discussion on inlines. It would be great to make this an
inline rather than a macro.
K
From: Python-Dev [mailto:python-dev-
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Skip Montanaro
> Sent: 27. febrúar 2014 19:12
> To: python-dev Dev
> Subject: Re: [Python-Dev] Start writing inlines rather than macros?
> one question though. Suppose you
I agree with NICK. having REF in it is a good idea.
So, I'm +1 on setref.
Having long explicit macros with exact semantics in the name is a bad one.
so I'm -1 on any Py_DECREF_AND_REPLACE or similar daschhunds.
Also, is there any real requirement for having separate non-X versions of these?
The X
> -Original Message-
> From: Victor Stinner [mailto:victor.stin...@gmail.com]
> Sent: 27. febrúar 2014 10:47
> To: Kristján Valur Jónsson
> Cc: Python-Dev (python-dev@python.org)
> Subject: Re: [Python-Dev] Start writing inlines rather than macros?
> In practice, r
Hi there.
The discussion on http://bugs.python.org/issue20440 started me thinking that
much of this
bikeshedding could be avoided if we weren't constrained to writing macros for
all of this stuff.
For example, a
Py_INLINE(PyObject *) Py_Incref(PyObject *obj)
{
Py_INCREF(obj);
return obj;
How often I hear this argument :)
For many people, serialized data is not persisted. But used e.g. for sending
information over the wire, or between processes.
Marshal is very good for that. Additionally, it doesn't have any side effects
since it just stores primitive types and is thus "safe".
“Note this happens only if there is a tuple in the tuple of the datalist.”
This is rather odd.
Protocol 3 adds support for object instancing. Non-trivial Objects are looked
up in the memo dictionary if they have a reference count larger than 1.
I suspect that the internal tuple has this property,
Hi there.
I think you should modify your program to marshal (and load) a compiled module.
This is where the optimizations in versions 3 and 4 become important.
K
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Victor Stin
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Nick Coghlan
> Sent: Wednesday, January 22, 2014 19:45
> To: Paul Moore
> Cc: Python-Dev
> Subject: Re: [Python-Dev] Enable Hostname and Certificate Chain Validation
> Righ
mojibake
On 12/01/14 16:52, Kristján Valur Jónsson wrote:
> Now you're just splitting hairs, Nick.
>
> An explicit operator, %s, _defined_ to be "encode a string object using
> strict ascii",
I don't like this because '%s' reads to me as "insert *string
ytes. That way
madness lies.
K
________
From: Paul Moore [p.f.mo...@gmail.com]
Sent: Sunday, January 12, 2014 17:04
To: Kristján Valur Jónsson
Cc: Nick Coghlan; Georg Brandl; python-dev@python.org
Subject: Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake
On 1
_
From: Nick Coghlan [ncogh...@gmail.com]
Sent: Sunday, January 12, 2014 16:09
To: Kristján Valur Jónsson
Cc: python-dev@python.org; Georg Brandl
Subject: Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake
It is not explicit, it is implicit - whether or not the resulting
Well, my suggestion would that we _should_ make it work, by having the %s
format specifyer on bytes objects mean: str(arg).encode('ascii', 'strict')
It would be an explicit encoding operator with a known, fixed, and well
specified encoder.
This would cover most of the use cases seen in this thre
lf of Serhiy Storchaka [storch...@gmail.com]
Sent: Saturday, January 11, 2014 21:01
To: python-dev@python.org
Subject: Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake
11.01.14 21:40, Kristján Valur Jónsson написав(ла):
> How about a compromise?
> Personally, I think adding the full co
Hi there.
How about a compromise?
Personally, I think adding the full complement of integer/float formatting to
bytes is a bit over the top.
How about just supporting two format specifiers?
%b : interpolate a bytes object. If it doesn't have the buffer interface,
error.
%s : interpolate a str ob
I don't know what the fuss is about. This isn't about breaking the text model.
It's about a convenient way to turn text into bytes using a default, lenient,
way. Not the other way round.
Here's my proposal
b'foo%sbar' % (a)
would implicitly apply the following function equivalent to every obje
...@gmail.com]
Sent: Thursday, January 09, 2014 18:08
To: Kristján Valur Jónsson
Cc: Victor Stinner; Antoine Pitrou; python-dev@python.org
Subject: Re: [Python-Dev] Python3 "complexity"
http://python-notes.curiousefficiency.org/en/latest/python3/text_file_processing.html
is currently linke
> -Original Message-
> From: Victor Stinner [mailto:victor.stin...@gmail.com]
> Sent: 9. janúar 2014 13:51
> To: Kristján Valur Jónsson
> Cc: Antoine Pitrou; python-dev@python.org
> Subject: Re: [Python-Dev] Python3 "complexity"
>
> 2014/1/9 Kristján V
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Kristján Valur
> Jónsson
> Sent: 9. janúar 2014 13:37
> To: Antoine Pitrou; python-dev@python.org
> Subject: Re: [Python-Dev] Python3 "complexit
Jan 2014 12:55:35 +
> Kristján Valur Jónsson wrote:
> > > If you don't "care" about the encoding, why don't you use latin1?
> > > Things will roundtrip fine and work as well as under Python 2.
> >
> > Because latin1 does not define all code
Jan 2014 10:15:08 +
> Kristján Valur Jónsson wrote:
> >
> > Moving to python 3, I found that this quickly caused problems. So, I
> > explicitly added an encoding. Better guess an encoding, something that is
> likely, e.g. cp1252 with open(fn1, encoding='cp125
> -Original Message-
> From: Paul Moore [mailto:p.f.mo...@gmail.com]
> Sent: 9. janúar 2014 10:53
> To: Kristján Valur Jónsson
> Cc: Stefan Ring; python-dev@python.org
> > Moving to python 3, I found that this quickly caused problems.
>
> You don't
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Stefan Ring
> Sent: 9. janúar 2014 09:32
> To: python-dev@python.org
> Subject: Re: [Python-Dev] Python3 "complexity"
>
> > just became harder to use for that purpose.
>
>
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Ben Finney
> Sent: 9. janúar 2014 00:50
> To: python-dev@python.org
> Subject: Re: [Python-Dev] Python3 "complexity"
>
> Kristján Valu
Just to avoid confusion, let me state up front that I am very well aware of
encodings and all that, having internationalized one largish app in python 2.x.
I know the problems that 2.x had with tracking down the source of errors and
understand the beautiful concept of encodings on the boundary.
s+kristjan=ccpgames@python.org] on
behalf of Ben Finney [ben+pyt...@benfinney.id.au]
Sent: Thursday, January 09, 2014 00:07
To: python-dev@python.org
Subject: Re: [Python-Dev] Python3 "complexity"
Kristján Valur Jónsson writes:
> Python 3 forces you to think about abstract concept
Believe it or not, sometimes you really don't care about encodings.
Sometimes you just want to parse text files. Python 3 forces you to think
about abstract concepts like encodings when all you want is to open that .txt
file on the drive and extract some phone numbers and merge in some email
a
Sent: 30. nóvember 2013 03:39
To: Kristján Valur Jónsson
Cc: Antoine Pitrou; python-dev@python.org
Subject: Re: [Python-Dev] PEP process entry point and ill fated initiatives
On 30 November 2013 01:25, Kristján Valur Jónsson wrote:
> I know that Anatoly himself is a subject of long histor
es
>
> On Fri, 29 Nov 2013 09:16:38 +
> Kristján Valur Jónsson wrote:
> > Closing the ticket, twice, is a rude, and unnecessary action.
>
> Closing the ticket means "we don't believe there is an issue, or we don't
> think it would be reasonable to fix it&qu
Reading the defect, I find people being unnecessarily obstructive.
Closing the ticket, twice, is a rude, and unnecessary action. How about
acknowledging that these waters are dark and murky and help making things
better?
Surely, documenting processes can only be an improvement?
A lot has changed
Nov 2013 09:19:27 +
> Kristján Valur Jónsson wrote:
> >
> > For reasons of work and others, I never got round to creating that
> > branch but recently Stackless development has picked up the pace to
> > the point where we feel it necessary to break with strict 2.7 conforman
> > For Stackless, neither argument applies because 2.8 work would be done
> > by us and stackless has no particular allegiance towards either version.
>
> Stackless can release their own Stackless 2.8 if they want, but I don't get
> why
> CPython would have a 2.8 too.
Oh, this is the misunders
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Christian Tismer
> Sent: 20. nóvember 2013 23:37
> To: Barry Warsaw; python-dev@python.org
> Subject: Re: [Python-Dev] PEP 0404 and VS 2010
>
> Hey Barry,
>
> In any case,
> -Original Message-
> From: Victor Stinner [mailto:victor.stin...@gmail.com]
> Sent: 29. október 2013 21:30
> To: Kristján Valur Jónsson
> Cc: python-dev
> Subject: Re: [Python-Dev] Updated PEP 454 (tracemalloc): no more metrics!
> tracemalloc maintains a dictio
A
>
>
> disable() function:
>
> Stop tracing Python memory allocations and clear traces of
> memory blocks allocated by Python.
>
> I would disable to stop tracing, but I would not expect it to clear out the
> traces it had already captured. If it has to do that, please put
In that case, how about adding a client/server feature?
If you standardize the format, a minimal tracing client could write a log, or
send it to a socket, in a way that can be turned into a snapshot by a
corresponsing utility reading from a file or listenting to a socket.
Just a though. Could be
> -Original Message-
> From: Nick Coghlan [mailto:ncogh...@gmail.com]
> Sent: 24. október 2013 12:44
> To: Kristján Valur Jónsson
> Cc: Python Dev
> Subject: Re: [Python-Dev] Updated PEP 454 (tracemalloc): no more metrics!
> Not everything is a PC that you can just a
> -Original Message-
> From: Victor Stinner [mailto:victor.stin...@gmail.com]
> Sent: 24. október 2013 01:03
> To: Kristján Valur Jónsson
> Cc: Python Dev
> Subject: Re: [Python-Dev] Updated PEP 454 (tracemalloc): no more metrics!
>
>
> The use case of get_
This might be a good place to make some comments.
I have discussed some of this in private with Victor, but wanted to make them
here, for the record.
Mainly, I agree with removing code. I'd like to go further, since in my
experience, the less code in C, the better.
1) really, all that is requ
[mailto:victor.stin...@gmail.com]
> Sent: 19. júní 2013 15:59
> To: Kristján Valur Jónsson
> Cc: Python Dev
> Subject: Re: [Python-Dev] RFC: PEP 445: Add new APIs to customize Python
> memory allocators
>
> Is PyMemMappingAllocator complete enough for your usage at CCP Games?
Oh, it should be public, in my opinion.
We do exactly that when we embed python into UnrealEngine. We keep pythons
internal PyObject_Mem allocator, but have it ask UnrealEngine for its arenas.
That way, we can still keep track of python's memory usage from with the larger
application, even if
Right, think of the "ctxt" as a "this" pointer from c++.
If you have an allocator object, that you got from some c++ api, and want to
ask Python to use that, you need to be able to thunk the "this" pointer to get
at the particular allocator instance.
It used to be a common mistake when writing C
> -Original Message-
> I would like to remove the "GIL must be held" restriction from
> PyMem_Malloc(). In my opinion, the restriction was motived by a bug in
> Python, bug fixed by the issue #3329. Let me explain why.
>
...
>
> Removing the GIL restriction would help to replace direct
> Didn't know about Stackless Python. Is it faster than CPython?
>
> I'm developing an application that takes more than 5000 active threads,
> sometimes up to 10.
> Will it benefit from Stackless Python?
>
> Can I use it for WSGI with Apache httpd?
>
Stackless has its own website and mailin
Stackless python, already with their own special handling of GC finalization,
is excited by this development :)
K
From: Python-Dev [mailto:python-dev-bounces+kristjan=ccpgames@python.org]
On Behalf Of Gregory P. Smith
Sent: 22. maí 2013 07:03
To: Antoine Pitrou
Cc: Python-Dev
Subject: Re: [P
Hello python-dev.
I'm working on a patch to remove reference cycles from heap-allocated classes:
http://bugs.python.org/issue17950
Part of the patch involves making sure that descriptors in the class dictionary
don't contain strong references to the class itself.
This is item 2) in the defect de
And I should learn to read the entire thread before I start responding.
Cheers!
K
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Guido van
> Rossum
> Sent: 4. apríl 2013 22:47
> To: Brett Cannon
> Cc: PJ Eby; Nick Coghla
> -Original Message-
> From: PJ Eby [mailto:p...@telecommunity.com]
> Sent: 4. apríl 2013 20:29
> To: Guido van Rossum
> Cc: Kristján Valur Jónsson; Nick Coghlan; python-dev@python.org
> Subject: Re: [Python-Dev] relative import circular problem
>
>
+1. I was thinking along the same lines.
Allowing relative imports in "import module [as X]" statements.
If 'module' consists of pure dots, then "as X" is required.
Otherwise, if "as X" is not present, strip the leading dot(s) when assigning
the local name.
K
> -Original Message-
> From:
> -Original Message-
> From: Eric Snow [mailto:ericsnowcurren...@gmail.com]
> Sent: 4. apríl 2013 04:57
> > imported by both of the original modules. At that point, the code is
> > cleaner and more decoupled, and the uneven circular import support
> ceases to be a problem for that applica
pr 01, 2013, at 08:20 PM, Kristján Valur Jónsson wrote:
>
> >The relative import syntax
> >
> > (from foo import bar) is a getattr type of lookup (i.e. import foo,
> > then get attr from it).
> >
> >This is in contrast with absolute import
> >
> >
s.python.org/issue992389
warrants a fix. This issue is about general attributes of a module.
In the general case, this is probably unfixable. But access to a partially
constructed
module hierarchy through the import mechanism ought to be possible.
K
From: Nick Coghlan [mailto:ncogh..
2013 22:38
To: Kristján Valur Jónsson
Cc: python-dev@python.org
Subject: Re: [Python-Dev] relative import circular problem
the latter works with partially initialized modules, but not the former,
rendering two sibling modules unable to import each other using the relative
syntax.
Clarification
I just ran into the issue described in
http://stackoverflow.com/questions/6351805/cyclic-module-dependencies-and-relative-imports-in-python.
This is unfortunate, because we have been trying to move towards relative
imports in order to aid flexibility in package and library design.
The relative
The compiler complains about this line:
if (c == '\n' | c=='\r') {
Perhaps you wanted a Boolean operator?
-Original Message-
From: Python-checkins
[mailto:python-checkins-bounces+kristjan=ccpgames@python.org] On Behalf Of
r.david.murray
Sent: 19. mars 2013 19:42
To: python-check...@
Apparently timemodule is not a built-in module on linux. But it is on windows.
Funny!
-Original Message-
From: Python-Dev [mailto:python-dev-bounces+kristjan=ccpgames@python.org]
On Behalf Of Kristján Valur Jónsson
Sent: 19. mars 2013 12:34
To: python-dev@python.org
Subject: Re
f01
> changeset: 82764:8ec39bfd1f01
> branch: 2.7
> parent: 82740:b10ec5083a53
> user: Kristján Valur Jónsson
> date:Tue Mar 19 10:58:59 2013 -0700
> summary:
> Issue #9090 : Error code 10035 calling socket.recv() on a socket
> with a timeout (WSAE
Hi python dev.
I have two languishing defects regarding 2.7 and how buffer support isn't
complete there.
http://bugs.python.org/issue10211
http://bugs.python.org/issue10212
In both cases, the new style buffer support is incomplete, and the patches
close usability holes having to do with memoryvi
We do that, of course, but compiling python without the doc strings removes
those from all built-in modules as well.
That's quite a lot of static data.
K
-Original Message-
From: Victor Stinner [mailto:victor.stin...@gmail.com]
Sent: 27. janúar 2013 21:58
To: Kristján Valur Jónss
We (CCP) are certainly compiling python without docstrings for our embedded
platforms (that include the PS3)
Anyone using python as en engine to be used by programs and not users will
appreciate the deletion of unneeded memory.
K
-Original Message-
From: Python-Dev [mailto:python-dev-bou
The memory part is also why I am interested in this approach.
Another thing has been bothering me. This is the fact that with the default
implementation, the smll table is only ever populated up to a certain
percentage, I cant recall, perhaps 50%. Since the small table is small by
definition,
I ran into this the other day. I had put in hooks in the PyMem_MALLOC to track
memory per tasklet, and it crashed
in those cases because it was being called without the GIL. My local patch was
simply to _not_ release the GIL.
Clearly, calling PyMem_MALLOC without the GIL is an API violation.
K
How serendipitous, I was just reporting a similar problem to Sony in one of
their console sdks yesterday :)
Indeed, the Nagle problem only shows up if you are sending more than one
segments that are not full size.
It will not occur in a sequence of full segments. Therefore, it is perfectly
ok t
Indeed, I had to change the dict tuning parameters to make dicts behave
reasonably on the PS3.
Interesting stuff indeed.
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Barry Warsaw
> Sent: 10. desember 2012 15:28
> To:
I'm sorry, I thought it was something that people did more often, to create
different implementations of of the "socket" api, for which cPython provided a
mere reference implementation. I know of at least three different alternative
implementations, so I thought that the question were clear eno
ators. But if that were
the case, such loosely defined features of the socket API would need clearer
definitions.
K
> -Original Message-
> From: gvanros...@gmail.com [mailto:gvanros...@gmail.com] On Behalf
> Of Guido van Rossum
> Sent: 26. nóvember 2012 15:59
> To: Kristján
rk
> Sent: 26. nóvember 2012 16:05
> To: python-dev@python.org
> Subject: Re: [Python-Dev] Socket timeout and completion based sockets
>
> On 26/11/2012 11:49am, Kristján Valur Jónsson wrote:
> > However, other implementations of python sockets, e.g. ones that rely
> >
Regarding the recent discussion on python-ideas about asyncronous IO, I'd like
to ask a question about python socket's Timeout feature.
Specifically this: Is it a documented or a guaranteed feature that a
send/receive operation that times out with a socket.timeout error is
re-startable on that
Where in the tracker? I tried searching but didn't find it.
I contributed to the pep405 discussions with similar concerns back in march:
http://mail.python.org/pipermail/python-dev/2012-March/117894.html
From: Python-Dev [mailto:python-dev-bounces+kristjan=ccpgames@python.org]
On Behalf Of
I'm intrigued. I thought this was merely so that one could do
python -m mypackage.mysubpackage
Can you refer me to the rationale and discussion about this feature?
K
From: Nick Coghlan [mailto:ncogh...@gmail.com]
Sent: 18. nóvember 2012 11:25
To: Kristján Valur Jónsson
Cc: Christian T
But that's what hg clone does.
You have a lorry for your work at the mine. You don't need a Mini to go to the
fishmongers. You can use your lorry even if you are not going to dump a tonne
of ore on the pavement.
K
> -Original Message-
>
> What would be good would to be able to access
Thank you! The sensitivity of this issue obviously is born out of our
collective
bad conscience for this unjust incarceration.
K
> -Original Message-
> From: gvanros...@gmail.com [mailto:gvanros...@gmail.com] On Behalf
> Of Guido van Rossum
> >
> > This fixes a regression in marshal betw
Interesting work indeed.
From profiling CPython it has long been clear to me that enormous gains can be
made by making instruction dispatching faster. A huge amount of time is spent
in the evaluation loop. I have also been making small inroads to offline
bytecode optimization. Identifying com
ld be isolated.
Perhaps this is just a pipedream. Even unpossible. But it doesn't harm to try
to think about better ways to do things.
K
-Original Message-
From: Christian Tismer [mailto:tis...@stackless.com]
Sent: 15. nóvember 2012 23:10
To: Kristján Valur Jónsson
Cc: python-dev@
Hello there.
I'd like to have some pair of eyes on a couple of patches i´ve submitted.
http://bugs.python.org/issue16475
This fixes a regression in marshal between 2.x and 3.x, reinstating string
reuse and internment support. In addition, it generalizes string reuse to all
objects, allowing for
...@snakebite.org]
Sent: 16. nóvember 2012 12:13
To: Kristján Valur Jónsson
Cc: Benjamin Peterson; Python-Dev (python-dev@python.org)
Subject: Re: [Python-Dev] externals?
On Thu, Nov 15, 2012 at 01:20:09AM -0800, Kristj?n Valur J?nsson wrote:
> Perhaps the unix makefiles get the proper version, but a wind
manually.
Also, is there any reason to keep this in svn? Why not check this in to HG, we
need not worry about history, etc.
K
> -Original Message-
> From: Benjamin Peterson [mailto:benja...@python.org]
> Sent: 13. nóvember 2012 15:04
> To: Kristján Valur Jónsson
> Cc: Pyt
When python is being run from a compile environment, it detects this by looking
for "Lib" folders in directories above the one containing the executable.
(I always thought that this "special" execution mode, hardwired in, was a bit
odd, and suggested that this could be made a function of pep405)
This may be a silly question, but haven't the python externals been moved to HG
yet?
I usually work on cpython without bothering with the externals, but I found
today that I needed them. On Windows this is a bit of a bother. And I've
thrown away all my SVN stuff...
K
__
Hi there.
Not having kept up, I realized I failed to contribute to the What's new thingie.
Here's stuff I remember working on and putting in:
1.
pickling support for built in iterators (#14288)
2.
inter process socket duplication for windows (#14310)
3.
Progress callback for gc module (#10
> -Original Message-
> From: Victor Stinner [mailto:victor.stin...@gmail.com]
> Sent: 14. ágúst 2012 13:32
> To: Kristján Valur Jónsson
> Cc: Python Dev
> Subject: Re: [Python-Dev] AST optimizer implemented in Python
> > The problem is, there exists only b
> -Original Message-
> I moved the script to a new dedicated project on Bitbucket:
> https://bitbucket.org/haypo/astoptimizer
>
> Join the project if you want to help me to build a better optimizer!
>
> It now works on Python 2.5-3.3.
I had the idea (perhaps not an original one) that p
Python-Dev] test_hashlib
2012/7/21 Antoine Pitrou :
> Kristján Valur Jónsson wrote:
>>
>> The code will raise ValueError when int(1) is passed in, but the
>> unittests expect a TypeError.
>
> Well, if test_hashlib passes, surely your analysis is wrong, no?
In the normal case, yes:
I was hit by this today.
in test_hashlib.py there is this:
def test_unknown_hash(self):
self.assertRaises(ValueError, hashlib.new, 'spam spam spam spam spam')
self.assertRaises(TypeError, hashlib.new, 1)
but in hashlib.py, there is this code:
except ImportError:
pass # no e
unces+kristjan=ccpgames@python.org] fyrir hönd Kristján Valur
Jónsson [krist...@ccpgames.com]
Sent: 16. júlí 2012 09:42
To: python-dev@python.org
Efni: [Python-Dev] early startup error reporting failure
Hi there.
I've been busy taking the current beta candidate and merging it into the
stac
Hi there.
I've been busy taking the current beta candidate and merging it into the
stackless repo.
As expected, things don't just go smoothly and there are the usual startup
errors, this being a rather intrusive patch and all that.
However, I found that early startup errors were not being re
1 - 100 of 321 matches
Mail list logo
