Martin == Martin v Löwis [EMAIL PROTECTED] writes:
Martin Stephen J. Turnbull wrote:
Bengt The characters in b could be encoded in plain ascii, or
Bengt utf16le, you have to know.
Which base64 are you thinking about? Both RFC 3548 and RFC
2045 (MIME) specify subsets of
Guido van Rossum wrote:
On 2/19/06, Jeff Rush [EMAIL PROTECTED] wrote:
[Quoting Neal Norwitz]
I've heard of a bunch of people using --disable-unicode. I'm not sure
if it's curiosity or if there are really production builds without
unicode. Ask this on c.l.p too.
Do you know of any embedded
On Sat, 18 Feb 2006 09:59:38 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
[EMAIL PROTECTED] wrote:
Aahz wrote:
The problem is that they don't understand that Martin v. L?wis is not
Unicode -- once all strings are Unicode, this is guaranteed to work.
Well, after all the string literal
On 2/19/06, Steve Holden [EMAIL PROTECTED] wrote:
You are missing the rationale of the PEP process. The point is
*not* documentation. The point of the PEP process is to channel
and collect discussion, so that the BDFL can make a decision.
The BDFL is not bound at all to the PEP process.
Jeff Rush wrote:
Guido van Rossum wrote:
On 2/19/06, Jeff Rush [EMAIL PROTECTED] wrote:
[Quoting Neal Norwitz]
I've heard of a bunch of people using --disable-unicode. I'm not sure
if it's curiosity or if there are really production builds without
unicode. Ask this on c.l.p too.
Do you
I'm withdrawing the last proposal. I'm not convinced by the argument
that __contains__ should always return True (perhaps it should also
insert the value?), nor by the complaint that a holy invariant would
be violated (so what?).
But the amount of discussion and the number of different viewpoints
On Sat, 18 Feb 2006 23:33:15 +0100, Thomas Wouters [EMAIL PROTECTED] wrote:
On Sat, Feb 18, 2006 at 01:21:18PM +0100, M.-A. Lemburg wrote:
[...]
- The return value for the non-unicode encodings depends on the value of
the encoding argument.
Not really: you'll always get a basestring
Guido van Rossum wrote:
FWIW, it looks like all the sample templates are still wasting a lot
of horizontal space in the first two columns the second is almost
always empty. Perhaps the author of the change could be placed *below*
the timestamp instead of next to it? Also for all practical
On Sun, Feb 19, 2006, Josiah Carlson wrote:
I agree, there is nothing perfect. But at least in all of my use-cases,
and the majority of the ones I've seen 'in the wild', my previous post
provided an implementation that worked precisely like desired, and
precisely like a regular dictionary,
Jonathan Barbero wrote:
Hello!
My name is Jonathan, i´m new with Python.
I try this in the command line:
(-1)**(1/2)
1
This is wrong, i think it must throw an exception.
What do you think?
1/2
0
(-1)**0
1
It's fine.
If you want to get a floating point result
Georg,
Please do not respond to off-topic posts on python-dev without
redirecting them to comp.lang.python (or other suitable place). Thanks!
On Mon, Feb 20, 2006, Georg Brandl wrote:
Jonathan Barbero wrote:
Hello!
My name is Jonathan, i?m new with Python.
I try this in the command
2006/2/20, Jonathan Barbero [EMAIL PROTECTED]:
Hello!
My name is Jonathan, i´m new with Python.
Hello Jonathan. This list is only for developing Python itself, not
for developing in Python.
You should address this kind of question in comp.lang.python
(available as a newsgroup and a mailing
On Feb 20, 2006, at 5:41 AM, Guido van Rossum wrote:
...
Alternative A: add a new method to the dict type with the semantics of
__getattr__ from the last proposal, using default_factory if not None
(except on_missing is inlined). This avoids the discussion about
broken invariants, but one
On 2/16/06, John Marshall [EMAIL PROTECTED] wrote:
Hi,
Should I expect the virtual memory allocation
to go up if I do the following?
-
raw = open(data).read()
while True:
d = eval(raw)
-
I would have expected the memory allocated to the
object referenced by d to be
1/2
0
(-1) ** (1./2)
Traceback (most recent call last):
File stdin, line 1, in ?
ValueError: negative number cannot be raised to a fractional power
Regards,
Michael
On 2/20/06, Jonathan Barbero [EMAIL PROTECTED] wrote:
Hello!
My name is Jonathan, i´m new with Python.
I try this in
On Mon, 20 Feb 2006 05:41:43 -0800, Guido van Rossum [EMAIL PROTECTED]
wrote:
I'm withdrawing the last proposal. I'm not convinced by the argument
that __contains__ should always return True (perhaps it should also
insert the value?), nor by the complaint that a holy invariant would
be violated
Martin v. Löwis wrote:
John Marshall wrote:
Should I expect the virtual memory allocation
to go up if I do the following?
python-dev is a list for discussing development of Python,
not the development with Python. Please post this question
to [EMAIL PROTECTED]
For python-dev, a
Josiah == Josiah Carlson [EMAIL PROTECTED] writes:
Josiah I try to internalize it by not thinking of strings as
Josiah encoded data, but as binary data, and unicode as text. I
Josiah then remind myself that unicode isn't native on-disk or
Josiah cross-network (which stores and
On Mon, 20 Feb 2006 12:01:02 +, Paul Moore [EMAIL PROTECTED] wrote:
On 2/19/06, Steve Holden [EMAIL PROTECTED] wrote:
You are missing the rationale of the PEP process. The point is
*not* documentation. The point of the PEP process is to channel
and collect discussion, so that the BDFL
On 2/20/06, Aahz [EMAIL PROTECTED] wrote:
On Sun, Feb 19, 2006, Josiah Carlson wrote:
I agree, there is nothing perfect. But at least in all of my use-cases,
and the majority of the ones I've seen 'in the wild', my previous post
provided an implementation that worked precisely like
Op vr, 17-02-2006 te 23:22 +0100, schreef Martin v. Löwis:
That, in turn, is because nobody is so short of disk space that
you really *have* to share /usr/share across architectures,
I can see diskless thin clients that boot from flash memory doing things
like that? (E.g. having documentation
On 2/20/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
[GvR]
Alternative A: add a new method to the dict type with the semantics of
__getattr__ from the last proposal
Did you mean __getitem__?
Yes, sorry, I meant __getitem__.
--
--Guido van Rossum (home page:
Adam Olsen asked:
... d.getorset(key, func) would work in your use
cases?
It is an improvement over setdefault, because it
doesn't always evaluate the expensive func. (But
why should every call have to pass in the function,
when it is a property of the dictionary?)
It doesn't actually *solve*
On Feb 20, 2006, at 8:35 AM, Raymond Hettinger wrote:
[GvR]
I'm not convinced by the argument
that __contains__ should always return True
Me either. I cannot think of a more useless behavior or one more
likely to have
unexpected consequences. Besides, as Josiah pointed out, it is
Guido van Rossum wrote:
Alternative A: add a new method to the dict type with the semantics of
__getattr__ from the last proposal, using default_factory if not None
(except on_missing is inlined).
I'm not certain I understood this right but (after
s/__getattr__/__getitem__) this seems to
Just noticed this and wondered if it came under the Python should never
crash mantra. Should sys.getrecursionlimit() perhaps be taken into
account somewhere?
D = {'a': None}
for i in xrange(15):
... D = {'a': D}
...
D
{'a': {'a': {'a': {'a': {'a': {'a': {'a':
Adam Olsen [EMAIL PROTECTED] wrote:
Can you say, for the record (since nobody else seems to care), if
d.getorset(key, func) would work in your use cases?
It doesn't work for the multiset/accumulation case:
dd[key] += 1
- Josiah
___
Python-Dev
Yes, this is the type of thing we've been struggling with for years.
There used to be way more of these. I can't guarantee it'll be fixed
with priority (it's mostly of the then don't do that type) but
please do file a bug so someone with inclination can fix it. The same
happens for deeply
On 2/20/06, Steven Bethard [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Alternative A: add a new method to the dict type with the semantics of
[__getitem__] from the last proposal, using default_factory if not None
(except on_missing is inlined).
I'm not certain I understood this
Sorry to chime in so late, but why are we setting a value when the key
isn't defined?
It seems there are many situations where you want:
a) default values, and
b) the ability to determine if a value was defined.
There are many times that I want d[key] to give me a value even when
it isn't
Martin v. Löwis [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Terry Reedy wrote:
With a couple of more machines added, should there be two separate pages
for trunk and 2.4 builds? Or do most checkins affect both?
I'd like to avoid this, assuming that people only look at the
I'm thinking something mutch closer to this (note default_factory gets the key):
def on_missing(self, key):
if self.default_factory is not None:
value = self.default_factory(key)
if self.on_missing_define_key:
self[key] = value
return value
raise KeyError(key)
On 2/20/06,
On Mon, Feb 20, 2006, Adam Olsen wrote:
On 2/20/06, Aahz [EMAIL PROTECTED] wrote:
On Sun, Feb 19, 2006, Josiah Carlson wrote:
I agree, there is nothing perfect. But at least in all of my use-cases,
and the majority of the ones I've seen 'in the wild', my previous post
provided an
On 2/20/06, Josiah Carlson [EMAIL PROTECTED] wrote:
Adam Olsen [EMAIL PROTECTED] wrote:
Can you say, for the record (since nobody else seems to care), if
d.getorset(key, func) would work in your use cases?
It doesn't work for the multiset/accumulation case:
dd[key] += 1
This is
Manuzhai wrote:
No; nobody volunteered a machine yet (plus the hand-holding that
is always necessary with Windows).
What exactly is needed for this? Does it need to be a machine dedicated
to this stuff, or could I just run the tests once every day or so when I
feel like it and have
Alex Martelli wrote:
I prefer this approach over subclassing. The mental load from an
additional
method is less than the load from a separate type (even a
subclass). Also,
avoidance of invariant issues is a big plus. Besides, if this allows
setdefault() to be deprecated, it becomes an
Steven Bethard wrote:
Alternative A: add a new method to the dict type with the semantics of
__getattr__ from the last proposal, using default_factory if not None
(except on_missing is inlined).
I'm not certain I understood this right but (after
s/__getattr__/__getitem__) this seems to
On 2/20/06, Ian Bicking [EMAIL PROTECTED] wrote:
Would it be deprecated in 2.*, or start deprecating in 3.0?
3.0 will have no backwards compatibility allowances. Whenever someone
says remove this in 3.0 they mean exactly that. There will be too
many incompatibilities in 3.0 to be bothered with
On Feb 20, 2006, at 12:33 PM, Guido van Rossum wrote:
...
You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1
is perfectly fine there and hard to improve upon.
I see d[k]+=1 as a substantial improvement -- conceptually more
direct, I've now seen one more k than I had
On Feb 20, 2006, at 12:38 PM, Aahz wrote:
...
Can you say, for the record (since nobody else seems to care), if
d.getorset(key, func) would work in your use cases?
Because I haven't been reading this thread all that closely, you'll
have
to remind me what this means.
Roughly the same
On 2/20/06, Ian Bicking [EMAIL PROTECTED] wrote:
Also, is default_factory=list threadsafe in the same way .setdefault is?
That is, you can safely do this from multiple threads:
d.setdefault(key, []).append(value)
I believe this is safe with very few caveats -- setdefault itself is
On 2/20/06, Alex Martelli [EMAIL PROTECTED] wrote:
On Feb 20, 2006, at 12:33 PM, Guido van Rossum wrote:
...
You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1
is perfectly fine there and hard to improve upon.
I see d[k]+=1 as a substantial improvement --
Stephen J. Turnbull wrote:
Martin For an example where base64 is *not* necessarily
Martin ASCII-encoded, see the binary data type in XML
Martin Schema. There, base64 is embedded into an XML document,
Martin and uses the encoding of the entire XML document. As a
Martin
Guido van Rossum wrote:
Why are you so keen on using a dictionary to share data between
threads that may both modify it? IMO this is asking for trouble --
the advice about sharing data between threads is always to use the
Queue module.
I use them often for a shared caches. But yeah, it's
On Mon, Feb 20, 2006, Alex Martelli wrote:
On Feb 20, 2006, at 12:38 PM, Aahz wrote:
...
Can you say, for the record (since nobody else seems to care), if
d.getorset(key, func) would work in your use cases?
Because I haven't been reading this thread all that closely, you'll
have
to
Guido van Rossum wrote:
They don't; I think a separate page would be a fine idea.
Ok, I have now split this into three pages.
FWIW, it looks like all the sample templates are still wasting a lot
of horizontal space in the first two columns the second is almost
always empty. Perhaps the
Steve Holden wrote:
All formats would be improved of the headers could be made to float at
the top of the page as scrolling took place.
Can this be done in CSS? If so, contributions are welcome. If not,
can somebody prepare a modified page with the necessary changes
(preferably only additional
Martin v. Löwis wrote:
Steve Holden wrote:
All formats would be improved of the headers could be made to float at
the top of the page as scrolling took place.
Can this be done in CSS? If so, contributions are welcome.
Not as it is. The big table would have to be split so that there is one
M.-A. Lemburg wrote:
Note that this does not mean that we should forget about memory
consumption issues. It's just that if there's only marginal
interest in certain special builds of Python, I don't see the
requirement for the Python core developers to maintain them.
Well, the cost of Unicode
Jan Claeys wrote:
That, in turn, is because nobody is so short of disk space that
you really *have* to share /usr/share across architectures,
I can see diskless thin clients that boot from flash memory doing things
like that? (E.g. having documentation and header files and other
Michael Foord wrote:
Has a machine been volunteered ?
Not yet.
I have a spare machine and an always on connection. Would the 'right'
development tools be needed ? (In the case of Microsoft they are a touch
expensive I believe.)
Any build process would do. I would prefer to see the
I wrote:
# I want to do ``dd[item] += 1``
Guido van Rossum wrote:
You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1
is perfectly fine there and hard to improve upon.
Alex Martelli wrote:
I see d[k]+=1 as a substantial improvement -- conceptually more
direct, I've now
I have now produces a snapshot of a Win64 build for AMD64
processors (also known as EM64T or x64); this is different
from IA-64 (which is also known as Itanium)...
Anyway, the binaries are
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.13199.amd64.msi
This is from today's trunk. If
On 2/20/06, Steven Bethard [EMAIL PROTECTED] wrote:
I wrote:
# I want to do ``dd[item] += 1``
Guido van Rossum wrote:
You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1
is perfectly fine there and hard to improve upon.
Alex Martelli wrote:
I see d[k]+=1 as a
On 2/20/06, Raymond Hettinger
[EMAIL PROTECTED] wrote:
An alternative is to have two possible attributes:d.default_factory = listord.default_value = 0with an exception being raised when both are defined (the test is done when theattribute is created, not when the lookup is performed).
Why not
[Steven Bethard]
* Should default_factory be an argument to the constructor? The three
answers I see:
- No. I'm not a big fan of this answer. Since the whole point of
creating a defaultdict type is to provide a default, requiring two
statements (the constructor call and the
On 2/20/06, Dan Gass [EMAIL PROTECTED] wrote:
Why not have the factory function take the key being looked up as an
argument? Seems like there would be uses to customize the default based on
the key. It also forces you to handle list factory functions and constant
factory functions (amongst
On 2/20/06, Brett Cannon [EMAIL PROTECTED] wrote:
While #3 is my preferred solution as well, it does pose a Liskov
violation if this is a direct dict subclass instead of storing a dict
internally (can't remember the name of the design pattern that does
this). But I think it is good to have
On 2/20/06, Dan Gass [EMAIL PROTECTED] wrote:
Why not have the factory function take the key being looked up as an
argument?
This was considered and rejected already.
You can already customize based on the key by overriding on_missing()
[*]. If the factory were to take a key argument, we
Guido van Rossum wrote:
I see two alternatives.
Have you considered the third alternative that's been
mentioned -- a wrapper?
The issue of __contains__ etc. could be sidestepped by
not giving the wrapper a __contains__ method at all.
If you want to do an 'in' test you do it on the
underlying
Martin v. Löwis wrote:
Michael Foord wrote:
Has a machine been volunteered ?
Not yet.
I have a spare machine and an always on connection. Would the 'right'
development tools be needed ? (In the case of Microsoft they are a touch
expensive I believe.)
Any build
Michael Foord [EMAIL PROTECTED] wrote:
Martin v. Löwis wrote:
Any build process would do. I would prefer to see the official tools on
the buildbot (i.e. VS.NET 2003),
I can get a free academic license for VS.NET 2003 professional with my
university (MSDNAA), and I've also got a Windows
Regarding this Grammar change; (last October)
from argument: [test '=' ] test [gen_for]
to argument: test [gen_for] | test '=' test ['(' gen_for ')']
- to raise error for bar(a = i for i in range(10)) )
I think we should change it to
argument: test [gen_for] | test '='
Brett Cannon wrote:
While #3 is my preferred solution as well, it does pose a Liskov
violation if this is a direct dict subclass
I'm not sure we should be too worried about that.
Inheritance in Python has always been more about
implementation than interface, so Liskov doesn't
really apply in
[Martin v. Loewis wrote]
If you want to build extensions for this build using distutils, you
need to
...
2. open an AMD64 retail shell
...
It might be possible to drop 2) some day, but finding the SDK from
the registry is really tricky.
Look for:
def find_platform_sdk_dir()
here:
Greg Ewing wrote:
In other words, just because A inherits from B in
Python isn't meant to imply that an A is a drop-in
replacement for a B.
Hmm - this is interesting. I'm not arguing Liskov violations or anything
...
However, *because* Python uses duck typing, I tend to feel that
subclasses
Josiah Carlson wrote:
If you're up for it, I'm up for it. It'll take me a bit to get the
software on the machine. Want me to ping you when I get the toolset
installed?
Sure! That should work fine. It would be best if the buildbot would
run with the environment variables all set up, so that
Delaney, Timothy (Tim) wrote:
However, *because* Python uses duck typing, I tend to feel that
subclasses in Python *should* be drop-in replacements. If it's not a
drop-in replacement, then it should probably not subclass, but just use
duck typing (probably by wrapping).
Inheritance is more
Bengt Richter wrote:
On Sat, 18 Feb 2006 09:59:38 +0100,
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote:
Thinking about bytes recently, it occurs to me that bytes are really not
intrinsically
numeric in nature. They don't necessarily represent uint8's. E.g., a binary
Trent Mick wrote:
Look for:
def find_platform_sdk_dir()
here:
http://cvs.sourceforge.net/viewcvs.py/pywin32/pywin32/setup.py?view=markup
That is the best code I know for doing that.
Right; I was planning something similar (although I would probably
hard-code the 2003 SP1 registry
On Feb 20, 2006, at 3:04 PM, Brett Cannon wrote:
...
- Yes and it should be the only constructor argument. This is my
...
While #3 is my preferred solution as well, it does pose a Liskov
violation if this is a direct dict subclass instead of storing a dict
How so? Liskov's
[Alex]
I see d[k]+=1 as a substantial improvement -- conceptually more
direct, I've now seen one more k than I had seen before.
[Guido]
Yes, I now agree. This means that I'm withdrawing proposal A (new
method) and championing only B (a subclass that implements
__getitem__() calling
If you're willing to commit to running a buildbot, and the only thing
preventing you is shelling out $$$ to Microsoft, send me e-mail. I'll
compile a list to send to the PSF and we'll either poke Microsoft to
provide some more free licenses or pay for it ourselves. This is what
the PSF is for!
On Feb 20, 2006, at 5:05 PM, Raymond Hettinger wrote:
[Alex]
I see d[k]+=1 as a substantial improvement -- conceptually more
direct, I've now seen one more k than I had seen before.
[Guido]
Yes, I now agree. This means that I'm withdrawing proposal A (new
method) and championing only B (a
in two ways:
1) dict.get doesn't work for object dicts or in exec/eval contexts, and
2) dict.get requires me to generate the default value even if I'm not
going to use it, a process which may be expensive.
On 2/20/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Crutcher Dunnavant ]
There are
On 2/20/06, Guido van Rossum [EMAIL PROTECTED] wrote:
[stuff with typos]
Here's the proofread version:
I have a patch ready that implements this. I've assigned it to Raymond
for review. I'm just reusing the same SF patch as before:
http://python.org/sf/1433928 .
One subtlety: for maximal
Martin v. Löwis wrote:
Delaney, Timothy (Tim) wrote:
However, *because* Python uses duck typing, I tend to feel that
subclasses in Python *should* be drop-in replacements. If it's not a
drop-in replacement, then it should probably not subclass, but just
use duck typing (probably by
On Feb 20, 2006, at 6:48 PM, Guido van Rossum wrote:
On OSX (10.4.4) the readline module in the svn HEAD fails compilation
as follows. This is particularly strange since the buildbot is green
for OSX... What could be up with this?
building 'readline' extension
-lots of build junk-
In
[Aahz]
If you're willing to commit to running a buildbot, and the only thing
preventing you is shelling out $$$ to Microsoft, send me e-mail. I'll
compile a list to send to the PSF and we'll either poke Microsoft to
provide some more free licenses or pay for it ourselves. This is what
the
Martin == Martin v Löwis [EMAIL PROTECTED] writes:
Martin Please do take a look. It is the only way: If you were to
Martin embed base64 *bytes* into character data content of an XML
Martin element, the resulting XML file might not be well-formed
Martin anymore (if the encoding of
On 2/20/06, Jim Jewett [EMAIL PROTECTED] wrote:
Adam Olsen asked:
... d.getorset(key, func) would work in your use cases?
It is an improvement over setdefault, because it doesn't
always evaluate the expensive func. (But why should every
call have to pass in the function, when it is a
On Sat, 2006-02-18 at 12:53 +0100, Pierre Barbier de Reuille wrote:
Guido Over lunch with Alex Martelli, he proposed that a subclass of
Guido dict with this behavior (but implemented in C) would be a good
Guido addition to the language.
I agree that .setdefault() is a
On Feb 20, 2006, at 7:25 PM, Stephen J. Turnbull wrote:
Martin == Martin v Löwis [EMAIL PROTECTED] writes:
Martin Please do take a look. It is the only way: If you were to
Martin embed base64 *bytes* into character data content of an XML
Martin element, the resulting XML file
I am considering developing a PEP for enabling a mechanism to assign to
free variables in a closure (nested function). My rationale is that with the advent of PEP 227
, Python
has proper nested lexical scopes, but can have undesirable behavior
(especially with new developers) when a user makes
On Fri, 2006-02-17 at 11:09 -0800, Guido van Rossum wrote:
Thanks for all the constructive feedback. Here are some responses and
a new proposal.
- Yes, I'd like to kill setdefault() in 3.0 if not sooner.
A worthy goal, but not possible unless you want to break existing code.
I don't think
Guido But shouldn't we try to fix setup.py to detect this situation
Guido instead of making loud clattering noises?
Here's a first-cut try at a setup.py patch:
http://python.org/sf/1435651
Unfortunately, I don't think distutils provides a clean way to detect
symbols the way
Adam Olsen [EMAIL PROTECTED] wrote:
However, I'm beginning to think we shouldn't be comparing them.
defaultdict is a powerful but heavyweight option, intended for
complicated behavior.
Check out Guido's patch. It's not that heavyweight, and its intended
behavior is to make some operations
[Guido]
...
What's the practical use case for not wanting __contains__() to
function?
I don't know. I have practical use cases for wanting __contains__()
to function, but there's been no call for those. For an example,
think of any real use ;-)
For example, I often use dicts to represent
Almann T. Goo [EMAIL PROTECTED] wrote:
I would like the community's opinion if there is enough out there that think
this would be a worthwile endevour--or if there is already an initiative
that I missed. Please let me know your questions, comments.
-1
Mechanisms which rely on manipulating
Mechanisms which rely on manipulating variables within closures or
nested scopes to function properly can be elegant, but I've not yet seen
one that *really* is.
This really isn't a case for or against what I'm proposing since we
can already do this in today's Python with mutable variables in
On Feb 21, 2006, at 6:53 AM, Bengt Richter wrote:
Perhaps a more informative message would be nice.
Here's an easy way to trigger it:
compile(#-*- coding: ascii -*-\nprint 'ab%c'\n%0x80, '','exec')
Traceback (most recent call last):
File stdin, line 1, in ?
MemoryError
Definitely
91 matches
Mail list logo
