Christian Heimes wrote:
But it is a convenient oddity nonetheless.
What's convenient about it? Seems to me it's the
opposite, since you can't just bail out if it
fails, but have to decref the reference you
thought it was going to take care of for you.
--
Greg
_
Cameron Simpson wrote:
But people not using threads, or at any rate not
dedicating a thread to the reading task, don't have such luxury.
But without a dedicated thread you need to use
select() or poll(), and then buffering causes other
headaches.
Are we disputing the utility of being able to
Lucas P Melo wrote:
The problem is that the chosen
method to accomplish it would read 2 symbols (bytes) ahead and this guy
is using peek() to grab these 2 bytes. The program will seem to work
correctly most of the time, but on the 4095th byte read, he would grab 1
byte at most using peek()
Lucas P Melo wrote:
Am I understanding this correctly:
* The blocking version would not do any raw reads.
No, the blocking version would keep doing raw reads
until the buffer contains enough bytes.
--
Greg
___
Python-Dev mailing list
Python-Dev@pyth
Daniel Diniz wrote:
Apocalypse Python !!, you say? Maybe something that conveys a security
message or anything that doesn't relate to the end of the world could
work better.
I guess the idea is meant to be that it's safe enough to
use for something that would result in the end of the
world if
P.J. Eby wrote:
In effect, 2.6 forces you to have a common known base class *other* than
'object' in order to write co-operative classes. :-(
You have to do that anyway if you want to make cooperative
calls to any method *other* that __init__.
--
Greg
Joshua Haberman wrote:
This is not as bad as having someone
set __class__ on one of my instances, or set attributes on my type, etc.
Is there any real need to prevent someone from doing
those things?
Note that even when you are allowed to change the
__class__ of an instance, you're still preve
Joshua Haberman wrote:
Python as a language has chosen to "lock down" built-in
objects... If it's
important for the built-in types, why should it be less important for
mine?
I'm not really sure why so much trouble is taken to lock
down builtin types -- it seems to go against Python's
general c
Scott David Daniels wrote:
I find I have a need in randomized testing for a shorter version
of getstate, even if it _is_ slower to restore. When running
exhaustive tests, a failure report should show the start state
of the generator. Unfortunately, our current state includes a
625-element array
Jason R. Coombs wrote:
I had a use case that was compelling enough that I thought there
> should be something in functools to do what I wanted.
I think this is one of those things that a small minority of
people would use frequently, but everyone else would use
very rarely or never. The decisi
Benjamin Peterson wrote:
Why do you need to set Py_TPFLAGS_HEAPTYPE on your C type?
I think he *doesn't* want to set Py_TPFLAGS_HEAPTYPE, but
does want to create the type dynamically.
But I suspect this is actually FUD, and that letting
Py_TPFLAGS_HEAPTYPE be set wouldn't lead to anything
dis
Scott David Daniels wrote:
No, I don't really need MT. The others would be fine.
I'd love further details.
The one I've been working with is due to Pierre L'Ecuyer [1]
and is known as MRG32k3a. It's a combined multiple recursive
linear congruential generator with 6 words of state. The
formula
Martin Zugnoni wrote:
when I press
the triple zero key once, I receive three events from the single zero key.
I need to make a disctintion between these keys
Sounds like you can't, except perhaps by detecting
three '0' key events arriving at almost the same
time.
--
Greg
__
Antoine Pitrou wrote:
Did your coworker run any timings instead of basing his assumptions on bytecode
size?
In any case, what are you suggesting -- that the last value
returned by a function call in the body should be the
default return value?
I don't think the unpredictability that would int
Xavier Morel wrote:
I fail to grasp the unpredictability of "the last expression evaluated
in the body of a function is its return value".
It's unpredictable in the sense that if you're writing
a function that's not intended to return a value, you're
not thinking about what the last call you
Le mardi 01 septembre 2009 à 15:09 +0200, Xavier Morel a écrit :
"We" are not Erlang, Smalltalk, OCaml or Haskell either, sadly.
IIRC, the default return value of a Smalltalk method is
self, not the last thing evaluated.
(And no, that's not going to happen in Python either --
the BDFL has rej
Reid Kleckner wrote:
On one hand, you may not want to call the user's atexit handlers
multiple times from different processes if they have externally
visible effects. On the other hand, people seem to assume that
Py_Finalize will be called at process exit to do various cleanups. On
the third h
Brett Cannon wrote:
It isn't like it is checking
explicitly for a function or method, just that it can be called which
seems reasonable to me (unless PyCallable_Check() is as off as
callable() was).
I think it just checks that there's something in the
tp_call slot, which is reasonable -- if it'
Benjamin Peterson wrote:
It depends on whether you're keeping the "callable" object around or
not. Somebody could add a __call__ method later.
Good point. Removing the check sounds like the
right thing to do, then.
--
Greg
___
Python-Dev mailing lis
Xavier Morel wrote:
Methods yes (and that's one of the few Smalltalk design "features" I
consider truly dumb, considering it has message cascading)
Cascading is something different -- it's for sending
multiple messages to the *same* receiver. It's not
dumb to have both.
--
Greg
_
Eric Smith wrote:
Mark Dickinson and I agree that for numeric types, right alignment makes
much more sense as a default. And that's what %-formatting and
str.format() both do.
Is the new formatting supposed to behave the same way
as %-formatting for the same format codes? Because the
default
Nick Coghlan wrote:
Or, to put it another way, given an arbitrary host in a network (e.g.
your own machine or the default gateway) and the netmask for that
network, calculate the network address.
Some people have claimed that the gateway address of a
network isn't necessarily the zero address
R. David Murray wrote:
A network is conventionally represented by an IP address in which the
bits corresponding to the one bits in the netmask are set to zero, plus
the netmask.
Okay, that's clarified things for me, thanks.
In that case, we shouldn't be talking about a "network address"
at al
Andrew McNamara wrote:
I also suggest the AddressWithMask classes not have any network/container
behaviours for a similar reason. If the developer needs these, the
.network attribute is only a lookup away.
Another way to approach this would be for the Address
object to potentially have a 'netw
Peter Moody wrote:
I don't see where the confusion lies. You have an address
+ netmask. ergo, you have a Network object. The single address that
defines the base address (most commonly referred to as the network
address) is an Address object. there is no netmask associated with
that single addr
Peter Moody wrote:
the address with all of the hosts bits masked to zero is most commonly
referred to as the network address.
Then call the attribute 'network_address', not just 'network'.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
ht
Eric Smith wrote:
My only concern with this is a possible performance issue with v6
networks. Would this be implemented such that [-1] doesn't need to
iterate through the (possibly large) address space of a v6 network?
I'm not familiar with v6, but if netmasks work the same
way as they do in
Pascal Chambon wrote:
And let the
filepointer untouched, simply because there are no reasons to move it,
On some systems it may not be possible for the file pointer to
be positioned past the end of the file (I think Classic MacOS
was like that).
I had the feeling that IOErrors were for opera
Nick Coghlan wrote:
For example, a file not existing, a file being locked by another
process, and the user not having write permissions to the file are
problems that demand very different responses from the user.
You can display an error-specific message without having
to inspect the error cod
Steven D'Aprano wrote:
Using "truncate" to mean "increase in size" makes about as much sense as
having a list method called "remove" used to insert items. I can't
imagine what the committee who approved this were thinking.
I expect the reason is historical. Some time back in the
early days of
Pascal Chambon wrote:
Concerning the naming of truncate(), would it be possible to deprecate
it and alias it to "resize()" ? It's not very gratifying to have
duplicated methods at the beginning of a major release, but I feel too
that "truncate" is a misleading term, that had better be replac
Willem Broekema wrote:
The AND above (which I uppercased) is subtle but important. In the "x
op y" case with y being of a subclass of the class of x, if there is
no class in between x and y (excluding x, including y) that overrides
the __rop__ method, then y,__rop__(x) is *not* tried before
x.__
Chris Withers wrote:
But this isn't coercion! :-)
The raisin is probably hysterical. Once upon a time, Python
had a __coerce__ special method that took care of things
like this in a different (and inferior) way. It gradually
got replaced by the current scheme, but nobody changed the
section he
Nick Coghlan wrote:
The interpreter doesn't promise to call those slots with "self" first -
self will be the second argument in the "rop" case.
I know. My question is: How does it know whether a subclass
"has overridden __rop__" when there is no concept of an
__rop__ method distinct from the _
Ben Finney wrote:
It's a single operation as far as the parser is concerned, so there
needs to be a single term for it. That term is “subscript”.
How about something like "does not support the [] operation".
This refers directly to the syntax involved, rather than
using a typographical term t
Pascal Chambon wrote:
-> it seems that the only important matter is : file pointer positions
and bytes/characters read should always be the ones that the user
expects, as if there were no buffering.
That sounds right to me.
Q from me : What happens in read/write text files, when overwriting
Nick Coghlan wrote:
The use case for "given a netmask and an arbitrary host on that network,
give me the appropriate IPNetwork object" has been well established by
this discussion (although still isn't particularly well described even
in the latest PEP update). This is what "strict=False" covers
Michael Foord wrote:
Some of the error messages are truly awful though as things stand,
especially for someone new to Python. Try to read from a file handle
opened in read mode for example: IOError: [Errno 9] Bad file descriptor
Subdividing the IOError exception won't help with
that, because
Peter Moody wrote:
On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou wrote:
>
Assuming the Network type loses the notion of a specific host (or host address,
or `ip`) attached to it, yes.
this is "less useful (strictly removing functionality)" and is an
example of what I explicitly said I was
Michael Foord wrote:
Well, the file type knows what mode it is opened in so catching these
errors is really not difficult at all.
Yes, in this particular case it could do some checking of
its own before making the system call. But this still has
nothing to do with the exception hierarchy.
--
Michael Foord wrote:
You said that having an exception hierarchy was impossible because the
only information we have is the error number.
No, I said that having an exception hierarchy wouldn't
help you to sort out the different meanings of a single
error code.
If you have some *other* way of
Guido van Rossum wrote:
I've never heard of someone who had a use case for
denormalized fractions, but I don't doubt that Peter has a use case
for denormalized IPNetwork objects. (Do you doubt that Peter has such
a use case? If so, we have a much more fundamental disagreement.)
It would be inte
Steven D'Aprano wrote:
there's a mathematical operator called the mediant:
mediant(a/b, c/d) = (a+c)/(b+d)
That's a function of four arguments, not two!
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
s...@pobox.com wrote:
I have never completely wrapped my brain around optparse. Getopt I
just remember.
Seems to me that optparse and argparse are fairly similar
in their APIs, and that argparse isn't going to be significantly
easier to fit in one's brain than optparse.
There's an art to comi
Peter Moody wrote:
I've mentioned at least once (and others have mentioned as well) that
it's very common, when describing the ip address/prefix of a NIC to
write, "192.168.1.100/24"
Yes, but if you want to *retain* all of that information,
the object you have isn't just a "network", it's more
Paul Moore wrote:
I'd rather argparse (or any library function)
didn't call sys.exit on my behalf - it should raise an exception.
Actually, sys.exit() *does* raise an exception (i.e.
SystemExit) that you can catch if you want.
--
Greg
___
Python-Dev
Has anyone considered the idea of having the string % operator
behave intelligently according to the contents of the format
string?
If it contains one or more valid %-formats, use old-style
formatting; if it contains one or more valid {}-formats,
use new-style formatting.
Ambiguous cases could a
Peter Moody wrote:
it's useful to take an
address like 192.168.1.100/24 and derive a bunch of information from
it (like the network address, broadcast address, containing supernets,
etc), but still remember that the original address was 192.168.1.100.
having a separate class or two for this is ov
Martin v. Löwis wrote:
So if a decision was made to eventually remove % formatting, it would
be reasonable to start migrating code to PEP 3101. However, no such
decision has been made (and hopefully won't be throughout 3.x)
If it's not done during 3.x, then by the time 4.x comes
around, there
Yuvgoog Greenle wrote:
When is the else after a loop executed?
> 1. When the loop isn't entered at all.
2. When the loop terminates through exhaustion of the list (does this
include when the list was empty?)
3. When the loop didn't exit because of a break statement.
1 and 3 are just special
Paul Moore wrote:
linus and snoopy are hosts not networks, so
making them IPv4Network classes seems wrong. I'd instinctively make
them IPv4Address objects (which, I believe, would work).
However, by allowing IPNetwork objects to also contain
a host address, we seem to be officially sanctioning
Martin v. Löwis wrote:
So I propose that the python.org version is identified as "python".
But then we won't have a generic term for the language
itself, independent of any implementation.
The "c" in cpython doesn't necessarily have to refer
to the implementation language. Maybe it stands for
Stephen J. Turnbull wrote:
In the
modern environment bandwidth is not really a consideration,
That's no reason to squander it, though. Quoting the entire
message every time makes the size of the thread grow as
O(n**2), and makes things harder to read as well. That's
just senseless.
The only po
Cameron Simpson wrote:
Personally, I'm for the iteration spec in a lot of ways.
Firstly, a .get()/.pick() that always returns the same element feels
horrible. Is there anyone here who _likes_ it?
It doesn't sound very useful to me. However, an iterating
version of it doesn't sound any more us
Antoine Pitrou wrote:
Guido van Rossum python.org> writes:
Picking a random element can be done in O(1) only if the data
structure supports access by index, which Python's hash tables don't.
Well, at the implementation level, they can. You'd just have to pick a new
random index until it poin
Steven D'Aprano wrote:
I don't know how expensive it is to create a set iterator,
Not expensive enough to justify burdening the set type with
extra functionality that will be extremely rarely used.
--
Greg
___
Python-Dev mailing list
Python-Dev@pyth
John Arbash Meinel wrote:
He wanted to introduce a moratorium at least partially because he was
tired of endless threads about anonymous code blocks, etc. Which aren't
going to be included in the language anyway, so he may as well make a
point to say "and neither will anything else for a while".
Antoine Pitrou wrote:
The problem is when searching for /another/ object which hashes the same as
Decimal("NaN").
Maybe decimal NaNs should be unhashable, so that you can't
put them in a dictionary in the first place.
--
Greg
___
Python-Dev mailing
anatoly techtonik wrote:
why not to replace it with something that you can actually use, with
something that is at least extensible? So people will be interested to
learn and contribute.
IDLE is written in Python, so it's about as extensible
as you can get.
Seems to me the only kind of IDE th
Martin v. Löwis wrote:
If that imaginary editor has lots of build dependencies that make
it really difficult to use it, I would be opposed to including it.
If it requires one library that is typically already available on
a Linux system, it would be fine with me.
If I manage to get PyGUI into
Martin v. Löwis wrote:
> Some of the Python maintainers have recently started objecting to this
> setup, asking that the standard library should be split into separate
> packages that are released and distributed independent of Python. Others
> of us feel strongly that such a change should not be
You could use a class:
class factorial():
def fac(self, n):
if n == 0:
return 1
else:
return n * self.fac(n - 1)
def __call__(self, n):
return self.fac(n)
factorial = factorial()
print factorial(5)
--
Greg
_
Kristján Valur Jónsson wrote:
Yes, and a number of different workarounds. That's not really the issue. The
issue is that what looks like a perfectly safe idiom (calling a function
recursively) happens to create a reference cycle if that function is a closure.
This is a non-obvious "gotcha" t
Brett Cannon wrote:
Issue 5094 already has a patch that is nearly complete to provide a
default UTC object (and requisite changes to functions to no longer be
naive but to use UTC).
Are you sure it's really a good idea to default to UTC?
I thought it was considered a feature that datetime
obje
Dj Gilcrease wrote:
win2k and later have a form of sym link, the api for it is just not
provided in a nice simple app like it is on nix platforms.
Yes, it's possible to create symlinks on win2k using a
command line tool called 'linkd' (I've done it).
However, they're extremely dangerous, becau
Reminiscent of INTERCAL, where you had to say PLEASE at
regular but not too frequent intervals, or the compiler
would accuse you of being either too impolite or too
smarmy.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
Barry Warsaw wrote:
We discussed this at Pycon and agreed that we will not support source-less
deployments by default. The source file must exist or it will be an
ImportError.
This does not mean source-less deployments are not possible though. To
support this use case, you'd have to write a c
Michael Foord wrote:
I thought we agreed at the language summit that if a .pyc was in the
place of the source file it *could* be imported from - making pyc only
distributions possible.
Ah, that's okay, then. Sorry about the panic!
--
Greg
___
Pytho
Meador Inge wrote:
3. Using Decimal keeps the desired precision,
Well, sort of, but then you end up doing arithmetic in
decimal instead of binary, which could give different
results.
Maybe the solution is to give ctypes long double objects
the ability to do arithmetic?
--
Greg
__
Guido van Rossum wrote:
Their users are apparently too dumb to decode bytecode but smart
enough to read source code, even if they don't understand it, and this
knowledge could hurt them.
I think it's like putting a lock on your door. It won't
stop anyone who's determined to get in, but it make
Glenn Linderman wrote:
What I did was:
python -m test
ren test.pyc foo.py
foo.py
and it worked.
Source files mentioned on the command line aren't required to
have a .py extension. I think what's happening is that the
interpreter ignores the filename altogether in that case and
examines the c
Meador Inge wrote:
Even with the user-defined precision capabilities of the 'Decimal'
class? In other words, can I create an instance of a 'Decimal' that
behaves (in all operations: arithmetic, comparison, etc...) exactly as
the extended double precision type offered by a given machine?
It'
Floris Bruynooghe wrote:
(But even then I'm not
convinced that would double the stat calls for normal users, only for
those who only ship .pyc files)
It would increase the number of stat calls for normal
users by 50%. You would need to look for a .pyc in the
source directory, then .py in the so
Glenn Linderman wrote:
if the
command line/runpy can do it, the importer could do it. Just a matter
of desire and coding. Whether it is worth pursuing further depends on
people's perceptions of "kookiness" vs. functional and performance
considerations.
Having .py files around that aren't s
Floris Bruynooghe wrote:
Can't it look for a .py file in the source directory first (1st stat)?
When it's there check for the .pyc in the cache directory (2nd stat,
magic number encoded in filename), if it's not check for .pyc in the
source directory (2nd stat + read for magic number check).
Y
Robert Collins wrote:
In the special
case of probing for $name.$ext1, ...$ext2, ...$ext3, you generally hit
the same pages and don't incur additional page in costs.
So then looking for a .pyc alongside a .py or vice versa
should be almost free, and we shouldn't be worrying about
it.
hot cache
Glenn Linderman wrote:
If your text editor blows up because it is binary, it is a sad text editor.
Blow up is probably an exaggeration, but even just getting
a screen full of gibberish when I think I'm opening a
text file is a jarring experience.
If you have .py mapped to a text editor, that'
Ron Adam wrote:
What if ... a bytecode-only mode is triggered by "__main__" loading from
a bytecode file, otherwise the .py files are needed and are checked to
make sure the bytecode files are current.
That would preclude having a bytecode-only library that
could be used by a sourceful progra
Neil Hodgson wrote:
There
is the question of whether to force failure on Windows 2000 or just
remove it from the list of known-working platforms while still
allowing it to run.
I'd be grateful if you could refrain from doing anything to
actively break it. Win 2000 was the last version to be fre
Barry Warsaw wrote:
On Mar 03, 2010, at 07:37 PM, Jim Jewett wrote:
Couldn't vendors just replace the real .py files with empty files?
Yes, I think that's a possibility. What would people think about that?
Seems like a perverse thing to have to do to me.
Also a bit fragile, since you woul
Glenn Linderman wrote:
In this scenario, the .pyc files would still live in __pycache__ ?
Complete with the foo..pyc naming ?
It might be neater to have a separate cache directory
for each bytecode version, named __cache.__ or
some such.
--
Greg
__
Glyph Lefkowitz wrote:
if we're going to have it be something.something-else, can we please
make sure that .something-else is a common extension that means
"python bytecode cache"?
Maybe something like
__bytecode-__.pycache
?
--
Greg
___
Python-
Antoine Pitrou wrote:
Unless the .py files arrange to raise a syntax error on compiling.
I guess that prevents a total disaster, but the
program is still broken and you have to hunt down
the offending files and fix the timestamps -- if
it's even evident what the problem is and how to
fix it.
Antoine Pitrou wrote:
Actually, I find it neater to have a single cache directory. It makes
for much less clutter, and simpler ignore rules.
Another possibility would be to have a single top-level
cache directory with a subdirectory for each version:
__bytecode__.pycache//.pyc
I don't thin
Jeffrey Yasskin wrote:
The caller can't avoid the error here by querying the future, because
of the problem you point out below, so I'm inclined to think that "the
future was already started" should be a return value rather than an
exception (although that may be my C++ background showing throug
Antoine Pitrou wrote:
I would argue that a string is actually more Pythonic than
integers or anonymous objects repurposed as magic constants.
(I'm looking at things such as SEEK_SET and friends)
Strings are certainly preferable to ints, one reason being that
they display as something meaningfu
Phillip J. Eby wrote:
while at the same time creating yet another alternative (and
mutually incompatible) event loop system in the stdlib, beyond the ones
that are already in asyncore, tkinter, and the various SocketServer
subclasses.
Aaargh... that's the *last* thing we need!
I've been thin
Brian Quinlan wrote:
That recommendation was designed to make it easy to change the API
without breaking code.
I'd don't think that recommendation makes sense anymore any I'll update
the PEP.
I don't think there's anything wrong with stating that the
order of the arguments is not a guarante
Gregg Lind wrote:
Sorry, re: question one, forgive the ill-formed question. I meant more,
are the parser rules applied "first matching". Essentially trying to
confirm that the parser is "top down" or "bottom up" or whether or not
it even matters.
I think pgen would complain if you had two
Michael Foord wrote:
Wouldn't it have to be the Tcl event loop then?
No, tcl/tk would have to be threatened with the comfy chair
until it allowed itself to be spliced into the official
event loop somehow.
--
Greg
___
Python-Dev mailing list
Python-D
Mark Russell wrote:
Boolean flags are a common enough case that I'd be inclined to add a wrapper
method,
parser.add_bool_argument('--plot')
+1, this looks good.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
Steven Bethard wrote:
Because the names are so long and you'd have to import them, I've left
them as private attributes of the module, but if there's really
demand, we could rename them to argparse.StoreTrueAction, etc.
What's wrong with just StoreTrue?
--
Greg
___
Terry Reedy wrote:
Looking more close, I gather that the prime
results will be printed 'in order' (waiting on each even if others are
done) while the url results will be printed 'as available'.
Seems to me that if you care about the order of the results,
you should be able to just wait for eac
Xavier Morel wrote:
So you'd have to write
add_argument('--plot', action=actions.store_true) which is straight from
the department of redundant redundancies.
This could easily be fixed with
from argparse.actions import store_true
An option would be
parser.add(actions.StoreTrue('--plot'
Dj Gilcrease wrote:
executor = executors.create(NAME, *args, **kwargs) # NAME is 'process'
or 'thread' by default
from concurrent.futures import executors, ExecutorBase
class MyExecutor(ExecutorBase): ...
executors.register(NAME, MyExecutor)
I don't understand the reason for using a registrat
Jon Ribbens wrote:
Sorry if I missed it, but why on earth is the bytecode directory
__pycache__ and not .pycache? (Or indeed anything else that starts
with a '.') Surely this is a classic ideal use case for a "hidden"
directory?
Please don't try to hide it. On MacOSX, it makes it impossible
to
Mark Dickinson wrote:
On the one hand there's something to be said for maintaining a clean
separation between the float and Decimal types, allowing only explicit
conversions from one to the other; mixed-type arithmetic between
floats and Decimals was very deliberately not permitted in the
origi
Mark Dickinson wrote:
On Tue, Mar 16, 2010 at 3:58 PM, P.J. Eby wrote:
If not, it might be confusing if a number that prints as '.1' compares
unequal to Decimal('.1').
Agreed, but this is just your everyday floating-point confusion, to be
dealt with by social means (e.g., educating the progr
Steven D'Aprano wrote:
More explicit than someDecimal == someFloat? Seems pretty explicit to
me.
Yes. I mean at least specifying either float(someDecimal) == someFloat
or someDecimal == Decimal(someFloat). Preferably also whether the
conversion is to be as exact as possible or on a minimum-d
Guido van Rossum wrote:
in some
"intuitive complexity" sense an int is a simpler type than a float and
a float is a simpler type than a Decimal
I don't think this analogy holds. In a mathematical sense,
ints are a subset of reals, but binary and decimal floats
are just alternative approximate r
801 - 900 of 2443 matches
Mail list logo
